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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document provides the protocol details for the presence service within the IP Multimedia (IM) Core 
Network (CN) subsystem based on the Session Initiation Protocol (SIP) and SIP Events as defined in 
3GPPTS 24.229 [9]. 

Where possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP and SIP Events, either directly, or as modified by 3GPP TS 24.229 [9]. 

Requirements for manipulation of presence data are defined by use of a protocol at the Ut reference point based on 
XML Configuration Access Protocol (XCAP) (RFC 4825 [33]). 

The present document is applicable to Application Servers (ASs) and User Equipment (UE) providing presence 
functionality. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 
[2] 3GPP TS 22.141: "Presence Service; Stage 1". 

[3] 3GPP TS 23 .002: "Network architecture" . 

[4] 3GPP TS 23.141: "Presence service; Architecture and functional description; Stage 2". 

[5] 3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2". 

[6] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[7] 3GPP TS 24. 109: "Bootstrapping interface (Ub) and Network application function interface (Ua); 

Protocol details". 

[8] 3GPP TS 24.228 Release 5: "Signalling fiows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[9J 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[10] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and 

message contents". 

[II] 3GPP TS 33.222: "Generic Authentication Architecture (GAA); Access to network application 
functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS)". 

[12] IETF RFC 2664 (1999): "FYI on Questions and Answers - Answers to Commonly asked New 

Internet User Questions". 

[13] IETF RFC 2246 (1999): "The TLS Protocol Version 1.0". 

[14] IETF RFC 2387 (August 1998): "The MIME Multipart/Related Content-type". 
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[15A] IETF RFC 2617 (June 1999): " HTTP Authentication: Basic and Digest Access Authentication". 

[16] IETF RFC 2778 (2000): "A Model for Presence and Instant Messaging". 

[17] IETF RFC 3261 (June 2002): "SIP: Session Initiation Protocol". 

[18] IETF RFC 3263 (June 2002): "Session Initiation Protocol (SIP): Locating SIP Servers". 

[19] IETF RFC 3265 (March 2002): "Session Initiation Protocol (SlP)-Specific Event Notification". 

[20] IETF RFC 3310 (2002): "Hypertext Transfer Protocol (HTTP) Digest Authentication Using 

Authentication and Key Agreement (AKA)". 

[21] IETF RFC 3863 (August 2004): "Presence Information Data Format (PIDF)". 

[22] IETF RFC 4662 (August 2006): "A Session Initiation Protocol (SIP) Event Notification Extension 

for Resource Lists". 
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for Partial Notification of Presence Information". 
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[25] draft-ietf-simple-prescaps-ext-07 (July 2006): "Session Initiation Protocol (SIP) User Agent 

Capability Extension to Presence Information Data Format (PIDF)". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[26] IETF RFC 4480 (July 2006): "RPID: Rich Presence Extensions to the Presence Information Data 

Format (PIDF)". 

[27] IETF RFC 3856 (August 2004): "A Presence Event Package for the Session Initiation Protocol 

(SIP)". 

[28] IETF RFC 3857 (August 2004): "A Watcher Information Event Template-Package for the Session 

Initiation Protocol (SIP)". 

[29] IETF RFC 3858 (August 2004): "An Extensible Markup Language (XML) Based Format for 

Watcher Information". 
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Event Notification Filtering". 
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[32] IETF RFC 4482 (July 2006): "CIPID: Contact Information for the Presence Information Data 

Format". 

[33] IETF RFC 4825 (May 2007): "The Extensible Markup Language (XML) Configuration Access 

Protocol (XCAP)". 
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Protocol (XCAP) Usage for Manipulating Presence Document Contents". 
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Resource Lists". 
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Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[39] draft-ietf-simple-xcap- diff-06 (August 2007): "An Extensible Markup Language (XML) 

Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) 
Resources". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[40] IETF RFC 4483 (May 2006): "A Mechanism for Content Indirection in Session Initiation Protocol 

(SIP) Messages". 

[41] draft-ietf-simple-common-policy-caps-00 (July 2005): "An Extensible Markup Language (XML) 

Representation for Expressing Policy Capabilities". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[42] draft-ietf-simple-pres-policy-caps-00 (July 2005): "An Extensible Markup Language (XML) 

Representation for Expressing Presence Pohcy Capabilities". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[43] draft-ietf-sipping-config-framework-12 (May 2007): "A Framework for Session Initiation Protocol 

User Agent Profile Delivery". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[44] IETF RFC 4479 (July 2006): "A Data Model for Presence" . 

[45] draft-ietf-simple-partial-publish-06 (February 2007): "Publication of Partial Presence 

Information" . 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 
[46] 3GPP2 X.S0027-004: "Network Presence". 

[47] VOID 

[48] 3GPP2 S.S0109: "Generic bootstrapping architecture" 

[49] 3GPP2 S.SOl 14: "Security mechanisms using GBA" 

[50] VOID 



3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

subscription authorization policy: a policy that determines which watchers are allowed to subscribe to diffa 
presentity's presence information 

The subscription authorization policy also determines to which presentity's presence information the watcher has access. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.141 [4] apply: 

Presence list server 
Presence Network Agent (PNA) 
Presence Server (PS) 
Presence User Agent (PUA) 

For the purposes of the present document, the following terms and definitions from RFC 2778 [16] apply: 
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Presence tuple 
Presentity 

For the purposes of the present document, the following terms and definitions from RFC 3903 [23] apply: 

Event Publication Agent (EPA) 
Event State Compositor (ESC) 

For the purposes of the present document, the following terms and definitions from RFC 4825 [33] apply: 

XCAP client 
XCAP server 

For the purposes of the present document, the following terms and definitions from RFC 4662 [22] apply: 

Resource List Server (RLS) 
For the purposes of the present document, the following terms and definitions given in RFC 1594 [12]. 

FuUy-QuaUfied Domain Name (FQDN) 

For the purposes of the present document, the following terms and definitions given in RFC 3261 [17] apply: 

Final response 

Header 

Header field 

Method 

Request 

Response 

(SIP) transaction 

Status-code (see RFC 3261 [17], subclause 7.2) 
Tag (see RFC 3261 [17], subclause 19.3) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [3], 
subclauses 4.1.1.1 and 4a.7 apply: 

Call Session Control Function (CSCF) 
Home Subscriber Server (HSS) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.218 [5], 

subclause 3.1 apply: 

Filter criteria 
Initial filter criteria 
Subsequent request 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [6], 
subclauses 4.3.3.1 and 4.6 apply: 

Interrogating-CSCF (I-CSCF) 
Proxy-CSCF (P-CSCF) 
Serving-CSCF (S-CSCF) 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [1] apply: 
User Equipment (UE) 

For the purposes of the present document, the following terms and definitions from 3GPP TS 33.222 [11] apply: 
Authentication Proxy 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



AS 




AUID 


Annliratinn TTniniip TT) 




V^VJIC i>ICLWwllv 


CPIM 


Oommon Profilp for Instant Mpssjipinp 


CSCF 


Call Spssion Control Piinotion 


EPA 


Pvpnt PiihliPfition A trpnt 


ESC 


Pvpnt S»tatp Comnositor 


HSS 


l-Tomp ^iih*;prihpr ^prvpr 


HTTP 


l-fvnprXpxt Xransfpr Protocol 


I-CSCF 


TntprrojratinjT - CSCF 


IM 


TP IVTiiltimprlia 


TOT 




IP 


TntPTTipl" Prr*tr*f*r*1 


MTMF 


TVyTnltirMimo^iP Tntpmpt IV^ml FYtpnsnrns 

IVALIILIL/Lll L/VJ AllL^lll^l. IVACUl J^A.l&lli3lUlli3 


P-PSPF 


ProYv - CSCF 


PIDF 


Presence Information Data. Forniat 


PNA 


Presence Network Apent 


PS 


P'TPQPTir'P Spn/PT 


PSI 


Piihlio Sprvirp IHpntitv 


PUA 


Presence User Agent 


RLMI 


Resource List Meta-Information 


RLS 


Resource List Server 


RPID 


Rich Presence Information Data 


S-CSCF 


Serving - CSCF 


SIP 


Session Initiation Protocol 


TLS 


Transport Layer Security 


UE 


User Equipment 


URI 


Universal Resource Identifier 


XCAP 


XML Configuration Access Protocol 


XML 


Extensible Markup Language 



4 Presence service overview 

The presence service provides the abiUty for the home network to manage presence information of a user's device, 
service or service media even whilst roaming. A user's presence information may be obtained through input from the 
user, information supplied by network entities or information supplied by elements external to the home network. 
Consumers of presence information, watchers, may be internal or external to the home network. The architecture for the 
3GPP presence service is specified in 3GPP TS 23.141 [4]. 

SIP and XCAP provide means to manipulate the presence status of a user. For details on the differences between those 
means refer to RFC 3903 [23] and RFC 4827 [34]. For details on the relationship of XCAP server to other roles see 
subclause 6.2.2. 
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5 SIP related procedures 

5.1 Introduction 

5.2 Functional entities 

5.2.1 User Equipment (UE) 

A UE shall implement the role of a PUA (see subclause 5.3.1), a watcher (see subclause 5.3.2) or both. 

5.2.2 Application Server (AS) 

An AS may implement one or more of the roles of a PUA (see subclause 5.3.1), watcher (see subclause 5.3.2), PS (see 
subclause 5.3.3), RLS (see subclause 5.3.4), or PNA (see subclause 5.3.5). 

5.3 Roles 

5.3.1 Presence User Agent (PUA) 

5.3.1.1 General 

A PUA is an entity that provides presence information to a PS. 

In addition to the procedures specified in subclause 5.3.1, the PUA shall support the procedures specified in 
3GPP TS 24.229 [9] appropriate to the functional entity in which the PUA is implemented. 

5.3.1 .2 Publication of presence information 

When the PUA intends to publish its own view of the presentity's presence information, it shall generate a PUBLISH 
request by acting as an Event Publication Agent (EPA) in accordance with RFC 3903 [23]. 

NOTE 1 : The contents of the presence event package containing the event state of the EPA, and how such 
information is constructed, are outside the scope of this version of the specification. However 
implementations will need to take into account the reporting needs of the EPA, and iilso the needs of the 
EPA to override information published by another EPA relating to the same presentity. 

The PUA shall implement the "application/pidf+xml" content type as described in RFC 3863 [21] ,the Presence 
Information Data Format (PIDF) extensions defined in RFC 4480 [26]. 

The PUA may implement the PIDF extensions defined in RFC 4482 [32]. 

The PUA may implement location information according to the format defined in RFC 4119 [37]. 

NOTE 2: The categorization of presence attributes to generic information attributes and communication address 
specific attributes is done using the <person> and <tuple> elements as defined in RFC 4479 [44]. 

The PUA shall implement draft-ietf-simple-prescaps-ext [25] if it wants to make use of SIP user agent capabilities in 
the presence document. The extension may be used for describing the type of the service described by the presence 
tuple. 

The PUA may implement draft-ietf-simple-partial-publish |45J if it wants to use the partial publication mechanism. The 
first partial PUBLISH request shall contain the full state. The PUA uses the "application/pidf-diff+xml" content type as 
described in draft-ietf-simple-partial-pidf-format [38] . 
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The PUA shall update the presence information, either 600 s before the publication expiration time if the publication 
period indicated from the PS in the response to the PUBLISH request was for greater than 1 200 s, or when half of the 
time has expired if the publication period was for 1 200 s or less, unless the PUA has determined that an update to the 
presence information is not required. 

When the PUA intends to show different value of the same presence attribute to different watchers, the PUA shall 
publish a tuple or person element for every value it intends to show, all including a different value of the same presence 
attribute. The PUA shall label different information with different value of the <class> element in every published tuple 
or person element as defined in RFC 4480 [26]. The PUA shall also authorize different tuples to different watchers or 
watcher groups by manipulating the subscription authorization policy as defined in subclause 6.3.1.2. 

If a local configuration information hmiting the rate at which PUA is allowed to generate PUBLISH requests is 
available, then PUA shall take that information into account. Such local configuration information could be e.g. the 
shortest time period between consecutive PUBLISH requests. 

5.3.1 .3 Mapping of presence attributes 

The extensible Markup Language (XML) Schema Definition of the "application/pidf+xml" format covers the definition 
of the 3GPP subscriber's presence attributes and the PUA shall perform the following mapping: 

- the communication address (containing communication means, status and contact address) attribute and the 
priority attribute are represented by a <luple> element including a basic <status> element and a <contact> 
elements containing a priority attribute as defined in RFC 3863 [21]. 

The PUA represents subscriber specific information by including a <person> element defined in RFC 4479 [44]. 
The person element may contain e.g. <activities> and <place-type> elements both defined in RFC 4480 [26]. 
Further PIDF extensions as defined in RFC 4482 [32] can also be used. 

NOTE 1: RFC 4479 [44] defines also a <device> element which can be used to present device specific information. 

- the text attribute is represented by the <note> element as defined in RFC 3863 [21] for <tuple> elements and in 
RFC 4480 [44] for <person> and <device> elements; and 

the location attribute is represented by the elements defined in RFC 4119 [37] and the <place-type> element 
defined in draft-ietf-simple-rpid [26]. 

NOTE 2: Only information elements either relevant for the application or recommended by the presence-data 

model RFC 4479 [44] are included in the PUBLISH request. Attributes not relevant or available (e.g. the 
text attribute or the location attribute) are omitted. 

Additional extensions can be used to express application specific attributes, but their usage is outside the scope of this 
version of the specification. 

5.3.1 .4 Storing presence attributes by multipart/related or content indirection 

The PUA shall implement the "multipart/related" content type as described in RFC 2387 [14] if it wants to aggregate 
other Multipurpose Internet Mail Extensions (MIME) objects with the "appUcation/pidf+xml" content type. 

When a presence attribute has a value of a MIME object, the PUA shall either: 

a) publish the presence document and the MIME object utilizing the "multipart/related" content-type in the 
PUBLISH request; or 

b) make use of content indirection. 

When the PUA decides to use the content indirection mechanism for publishing an initial or modified value of a 
presence attribute the PUA shall follow the following procedure: 

a) either store the MIME object behind an HTTP URI on the PS or ensure that the MIME object and a HTTP URL 
pointing to that MIME object already exists on the PS; 
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b) use the "multipart/related" content type as described in RFC 2387 [14] with the content indirection mechanism 
as specified in RFC 4483 [40] for the publication of presence information format as follows: 

- set a CID URI referencing to other MIME multipart body. The other multipart body contains the content 
indirection information which is represented as the value of an XML element; 

- include the presence document of the format "appUcation/pidf+xml" or "appUcation/pidf-diff+xml" in the 
root of the body of the "multipart/related" content; 

- specify the part having information about the MIME object by using the "message/extemal-body" content 
type, defining the HTTP URI, versioning information and other information about the MIME object as 

described in RFC 4483 [40]. 

NOTE 1: The versioning information is used for determining whether or not the MIME object indirectly referenced 
by a URI has changed or not; 

When storing a MIME object on the PS the PUA shall: 

a) construct as many HTTP URls as the number of objects to be stored; and 

b) formulate every HTTP URI according to a predefined directory structure. 

NOTE 2: The PUA has the root directory for storing the MIME objects on the PS preconfigured. 

NOTE 3: The PUA needs to store the MIME objects on the PS behind the HTTP URI(s) created previously using 
standard HTTP procedures as defined in RFC 2616 [15]. 

5.3.1 .5 Subscription for tine watclier information event template pacl<age 

Upon activation of the presence service, the PUA application may subscribe for the watcher information state changes 
in accordance with RFC 3857 [28] and RFC 3858 [29]. 

The PUA application may include filters in the body of the SUBSCRIBE request in accordance with RFC 4661 [30] and 
RFC 4660 [31]. 

5.3.1 .6 Subscription for notification of state clianges in XML document 

In order to get notifications of changes to XML documents manipulated via the Ut reference point the PUA may 
generate a SUBSCRIBE request in accordance with draft-ietf-simple-xcap-diff [39] and draft-ietf-sipping-config- 
framework [43]. 

5.3.2 Watcher 

5.3.2.1 General 

A watcher is an entity that subscribes to or requests presence information about a presentity from the PS. 

In addition to the procedures specified in subclause 5.3.2, the watcher shall support the procedures specified in 
3GPP TS 24.229 [9] appropriate to the fimctional entity in which the watcher is implemented. 

5.3.2.2 Subscription for presence information state changes and notification 
acceptance 

When the watcher intends to subscribe for presence information state changes of a presentity, it shall generate a 
SUBSCRIBE request in accordance with RFC 3265 [19] and RFC 3856 [27]. 

The watcher shall implement the "application/pidf+xml" content type as described in RFC 3863 [21] , the PIDF 
extensions defined in RFC 4480 [26]. 

The watcher may implement the PIDF extensions defined in RFC 4482 [32]. 

The watcher may implement location information according to the format defined in RFC 4119 [37]. 
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The watcher shall implement draft-ietf-simple-prescaps-ext [25] if it wants to make use of SIP user agent capabilities 
extensions included in the presence document. The extension may be used by the watcher for interpreting the type of 
the service described by the presence tuple. 

The watcher may include filters in the body of the SUBSCRIBE request in accordance with RFC 4661 [30] and 
RFC 4660 [31]. 

The watcher may indicate its support for partial notification using the Accept header field in accordance with draft-ietf- 
simple-partial-notify [24]. 

The watcher shall interpret the received presence information according to RFC 4479 [44] and the following: 

a) a <person> element as defined in RFC 4479 [44] means information about the presentity; 

b) a tuple including a <relationship> element defined in RFC 4480 [26] means information about an alternate 
contact to the presentity; 

c) a tuple contains communication means specific information. The communication means described by the tuple is 
deduced from the URI scheme of the contact address information present in the <contact> element as defined in 
RFC 3863 [21]. If the URI scheme of the contact address information provides ambiguous information about the 
communication means, the watcher shall further examine other elements of the tuple to decide the 
communication mean. Such elements can be the <methods> element, any of the different media type specific 
elements as defined in draft-ietf-simple-prescaps-ext [25]. 

d) a <device> element as defined in RFC 4479 [44] means information about a device. 

Additional extensions can be used to express application specific attributes, but their usage is outside the scope of this 
version of the specification. 

5.3.2.3 Subscription for presence information state changes of presentity collections 

When the watcher intends to subscribe for presence information state changes of a presentity collection, it shall generate 
a SUBSCRIBE request in accordance with RFC 4662 [22J, additionally to the procedures described in 
subclause 5.3.2.2. 

5.3.2.4 Subscription for the watcher information event template package 

Upon activation of the presence service, the watcher may subscribe recursively for the watcher information state 
changes in accordance with RFC 3857 [28] and RFC 3858 [29]. 

The watcher may include filters in the body of the SUBSCRIBE request in accordance with RFC 4661 [30] and 
RFC 4660 [31]. 

5.3.2.5 Subscription for notification of state changes in XML document 

In order to get notifications of changes to XML documents manipulated via the Ut reference point the watcher may 
generate a SUBSCRIBE request in accordance with draft-ietf-simple-xcap-diff [39] and draft-ietf-sipping-config- 
framework [43]. 

5.3.3 Presence Server (PS) 
5.3.3.1 General 

A PS is an entity that accepts, stores, and distributes presence information. 

In addition to the procedures specified in subclause 5.3.3, the PS shall support the procedures specified in 
3GPP TS 24.229 [9] appropriate to the functional entity in which the PS is implemented. 
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5.3.3.2 Subscription acceptance to presence information and notification of state 
clianges 

When the PS receives a SUBSCRIBE request for the presence information event package, the PS shall first attempt to 
verify the identity of the source of the SUBSCRIBE request as described in 3GPP TS 24.229 [9] subclause 5.7.1.4, then 
perform authorization according to 3GPP TS 24.229 [9] subclause 5.7.1.5. In case of successful subscription, the PS 
shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 3265 [19] and 

RFC 3586 L27J. 

Additionally, in the special case of a watcher subscription if the subscription authorization poUcy results in the action to 
confirm the watcher subscription from the PUA and the PUA has a valid watcher information subscription, see 
RFC 3857 [28], then, the PS shall inform the PUA about the watcher subscription attempt. 

If the watcher has indicated the need for partial notification using the Accept header field, then the PS shall generate 
partial notifications in accordance with draft-ietf-simple-partial-notify [24] and draft-ietf-simple-partial-pidf- 
format [38]. 

If the body of the SUBSCRIBE request from the watcher contains filters, the PS shall apply the requested filtering 
function on notifications in accordance with RFC 4661 [30] and RFC 4660 [31]. 

If the watcher has indicated support for the "multipart/related" content type using the Accept header field, then the PS 
may generate notifications using "multipart/related" content type which aggregates "application/pidf+xml" formatted 
presence information with other MIME objects in accordance with RFC 2387 [14]. In this case, the PS shall modify the 
value of the presence attribute in the PIDF document to refer to the MIME object included in the corresponding MIME 
multipart body. If the watcher has not indicated support for the "multipart/related" or a MIME object cannot be accessed 
by the PS, the PS should exclude the presence attribute from the notification. 

NOTE: How the PS takes presence information from various presence sources, in order to generate a final 
presence document, is outside the scope of this version of the specification. Implementations need a 
flexible approach to composition policy and therefore to the collection, filtering and composition of 
presence documents. 

5.3.3.3 Publication acceptance of presence information 

The PS shall act as an Event State Compositor (ESC). 

When the PS receives a PUBLISH request, the PS shall first verify the identity of the source of the PUBLISH request as 
described in 3GPP TS 24.229 [9] subclause 5.7.1.4, then perform authorization according to 3GPP TS 24.229 [9] 
subclause 5.7.1.5. In case of successful authentication and authorization, the PS shall process the PUBLISH request in 
accordance with RFC 3903 [23]. 

If the PUBLISH request contains the "application/pidf-diff+xml" content-type as described in draft-ietf-simple-partial- 
pidf-format [38], the PS shall process the PUBLISH request in accordance with RFC 3903 [23] and draft-ietf-simple- 
partial-pubUsh [45]. 

If the PUBLISH request contains the "multipart/related" content type and the PS supports the content type, the PS shall 

process the content as follows: 

- if a MIME multipart contains a MIME object of a content type supported by the PS, either store the MIME 
object in case of initial publication or replace an existing content in case of modify operation; and 

- if a multipart includes the "message/external-body" content type and the content indirection as described in 
RFC 4483 [40] is supported by the PS, ensure that it has access to the MIME object indicated by the URl and 
that the MIME object exists; and associate the value of the presence attribute that refers to the MIME object with 
the MIME object and additional information about it. 

If the PS does not support the content type used for pubUshing MIME objects then the PS shall send a 415 
(Unsupported Media Type) response and indicate the supported content types in the Accept header. 
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NOTE: If the PS receives a HTTP request for storing a MIME object on the PS .meaning that the HTTP URI 
points to a predefined directory reserved for storing MIME objects and the request is an HTTP PUT 
request, the PS replaces any existing content referenced by the Request-URI with the content of the 
request. If the Request-URI points to an uncreated directory, the PS creates the directory, stores the 
content there and associates the content with the Request-URI. For all requests, i.e. HTTP PUT, HTTP 
GET and HTTP DELETE requests, the PS generates an appropriate response in accordance with 
RFC 2616 [15]. 

To receive 3GPP2 IP-CAN network presence information from the PNA, the PS shall support the XML extension 
defined in 3GPP2 X.S0027-004 [46]. 

5.3.3.4 Subscription acceptance to watclier information and notification of state 
clianges 

When the PS receives a SUBCRIBE request for the watcher information event template package, the PS shall first 
verify the identity of the source of the SUBSCRIBE request as described in 3GPP TS 24.229 [9] subclause 5.7.1.4, then 
perform authorization according to 3GPP TS 24.229 [9] subclause 5.7.1.5. In case of successful subscription, the PS 
shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 3265 [19], 

RFC 3857 [28] and RFC 3858 [29]. 

If the body of the SUBSCRIBE request from the PUA contains filters, the PS shall apply the requested filtering function 
on notifications in accordance with RFC 4661 [30] and RFC 4660 [31]. 

5.3.3.5 Subscription acceptance and notification of state clianges in XML document 

When the PS receives a SUBSCRIBE request having the Event header value "ua-profile", the PS shall first verify the 
identity of the source of the SUBSCRIBE request as described in 3GPP TS 24.229 [9] subclause 5.7.1.4, then it shall 
perform authorization as described in 3GPP TS 24.229 [9] subclause 5.7.1.5. Afterwards, the PS shall generate a 
response to the SUBSCRIBE request and notifications in accordance with draft-ietf-simple-xcap-diff [39] and draft-ietf- 
sipping-config-framework [43]. 

5.3.4 Resource List Server (RLS) 

5.3.4.1 General 

The Resource List Server (RLS) is an implementation of the presence list server. The RLS is an entity that accepts 
subscriptions to resource Usts and sends notifications to update subscribers of the state of the resources in a resource 
list. 

In addition to the procedures specified in subclause 5.3.4, the RLS shall support the procedmes specified in 
3GPP TS 24.229 [9] appropriate for an AS in which the RLS is implemented. 

5.3.4.2 Subscription acceptance to resource lists and notification of state changes 

When the RLS receives a SUBSCRIBE request for the presence information event package of a presentity collection, 
the RLS shall first verify the identity of the source of the SUBSCRIBE request as described in 3GPP TS 24.229 [9] 
subclause 5.7.1.4, then perform authorization according to 3GPP TS 24.229 [9] subclause 5.7.1.5. In case of successful 
subscription, the RLS shall generate a response to the SUBSCRIBE request and notifications in accordance with 
RFC 4662 [22] by adding a Require header field with value "eventlist". 

If the body of the SUBSCRIBE request from the watcher contains filters, the RLS shall apply the requested filtering 
function on notifications in accordance with RFC 4661 [30] and RFC 4660 [31]. 

5.3.4.3 Subscription to presence information 

When the RLS receives a SUBSCRIBE request for the presence information event package of a presentity collection 
and installs the corresponding subscription, the RLS shall resolve the list URI to individual URIs and generate 
SUBSCRIBE requests for each of the individual URIs as per the procedures in RFC 3265 [19], RFC 3856 [27] and 
RFC 4662 [22] if the state information for the resource represented by the individual URI is otherwise not available. 
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For internal virtual subscriptions, the detection of loops potentially caused by lists of lists is possible in RLS. However 
for back-end subscriptions (see RFC 4662 [22]), the detection of such situations is not possible in RLS. To prevent 
loops in subscriptions to non-local resources the RLS shall not insert "eventlist" in the "Supported" header of back-end 
subscriptions. 

5.3.4.4 Subscription acceptance and notification of state clianges in XML document 

When the RLS receives a SUBSCRIBE request having the Event header value "ua-profile", the RLS shall first verify 
the identity of the source of the SUBSCRIBE request as described in 3GPP TS 24.229 [9] subclause 5.7.1.4, then it 
shall perform authorization as described in 3GPP TS 24.229 [9] subclause 5.7.1.5. Afterwards, the RLS shall generate a 
response to the SUBSCRIBE request and notifications in accordance with draft-ietf-simple-xcap-diff [39] and draft-ietf- 
sipping-config-framework [43]. 

5.3.5 Presence Network Agent (PNA) 

5.3.5.1 General 

In addition to the procedures specified in subclause 5.3.5, the PNA shall support the procedures specified in 
3GPP TS 24.229 [9] appropriate to the functional entity in which the PNA is implemented. 

The PNA can collect presence information about the presentity from a number of core network entities. The PNA can 
combine information from viirious core network entities to form more complete presence information. 

Among these core network entities, the S-CSCF uses SIP to deliver presence information to the PNA over the Pi 
reference point as specified in subclause 5.3.5.2. 

NOTE: As part of the configuration of AS to provide a presence system, appropriate settings are downloaded to 

the initial filter criteria in the S-CSCF to ensure this occurs. The PNA will receive third-party REGISTER 
requests as specified in 3GPP TS 24.229 [9] subclauses 5.4.1.7 and 5.7.1.1. 

5.3.5.2 Subscription to reg event package 

On receiving a third-party REGISTER request which contains an Expires header with a non-zero value, the PNA shall, 
if no subscription already exists, subscribe to the reg event package for a particular user at the S-CSCF, as described in 
3GPP TS 24.229 [9] subclause 5.7.1.1. As a result, the S-CSCF will then provide the presence-related information as 
reg event packages in NOTIFY requests to the PNA. 

On receiving a third-party REGISTER request, the PNA may, if a subscription already exists, resubscribe to the reg 
event package for a particular user at the S-CSCF, as described in 3GPP TS 24.229 [9] subclause 5.7.1.1. As a result, 
the S-CSCF will then provide the presence-related information as reg event packages in NOTIFY requests to the PNA. 

5.3.5.3 Publication of network presence information 

To publish network presence information received from 3GPP2 IP-CAN, the PNA shall follow the procedures defined 
in 3GPP2 X.S0027-004 [46]. 



6 Protocol for data manipulation at the Ut reference 
point 

6.1 Introduction 

XML Configuration Access Protocol (XCAP) is used to store, alter and delete data related to the presence service. 
XCAP is designed according to the Hypertext Transfer Protocol (HTTP) framework, and uses the HTTP methods PUT, 
GET and DELETE for communication over the Ut reference point. The general information that can be manipulated is 
user groups, subscription authorization pohcy, resource lists, hard state presence publication, MIME objects referenced 
from the hard state presence information, etc. Soft state presence information manipulated with a PUBLISH request is 
not manipulated by the mechanism provided over the Ut reference point. 
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6.2 Functional entities 

6.2.1 User Equipment (UE) 

The UE implements the XCAP client role as described in subclause 6.3.1. 
For accessing presence servers in 3GPP system: 

1) The UE shall implement HTTP digest AKA (see RFC 3310 [20]) and it shall initiate a bootstrapping procedure with 
the bootstrapping server function located in the home network, as described in 3GPP TS 24.109 [7]. 

2) The UE shall acquire the subscriber's certificate from PKI portal by using a bootstrapping procedure, as described in 
3GPPTS 24.109 [7]; 

3) The UE shall implement HTTP digest authentication (see RFC 2617 [15A]); and 

4) The UE shall implement Transport Layer Security (TLS) (see RFC 2246 [13]). The UE shall be able to authenticate 
the network apphcation function based on the received certificate during TLS handshaking phase. 

For accessing presence servers in 3GPP2 system, the subscriber shall be authenticated by the presence server, 
subscriber authentication may be performed by the operator using proprietary or non-3G standardized methods. GBA 
defined in 3GPP2 S.S0109 [48] may also be used. If GBA based subscriber authentication is used, then the following 
shall apply: 

1) The UE shall implement bootsrapping procedures as specified in 3GPP2 S.S0109 [48]; and 

2) The UE shall implement TLS with pre-shared keys method specified in clause 5 of 3GPP2 S.SOl 14 [49]. 

6.2.2 Application Server (AS) 

If an AS implements the role of a PS (see subclause 5.3.3) or of a RLS (see subclause 5.3.4), then the AS shall also 
implement the role of a XCAP server (see subclause 6.3.2). 

If there is no authentication proxy in the network, then the AS in 3GPP system shall: 

1) implement the role of a network application function, as described in 3GPP TS 24.109 [7]; 

2) implement TLS (see RFC 2246 [13]); 

3) implement HTTP digest authentication (see RFC 2617 [15A]); and 

4) support certificate authentication. 

For 3GPP2 system, the authentication proxy does not apply. If GBA based authentication is used by an AS in 3GPP2 
system, then the AS shall: 

1) implement the role of a network application fimction, as described in 3GPP2 S.S0114 [49]; and 

2) implement TLS with pre-shared keys method specified in clause 5 of 3GPP2 S.SOl 14 [49]. 

6.2.3 Autlientication proxy 

For 3GPP2 system, this subclause does not apply. 

The generic requirements for an authentication proxy are defined in 3GPP TS 24.109 [7]. 

In addition an authentication proxy acting within the scope of presence shall: 

1) verify the content of the "X-3GPP- Intended-Identity" header in case it is available in HTTP requests; and 

2) indicate an asserted identity of the user in the "X-3GPP-Asserted-Identity" header in HTTP requests sent to the 
AS. 
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6.3 



Roles 



6.3.1 



XCAP client 



6.3.1.1 



Introduction 



The XCAP client is a logical function as defined in RFC 4825 [33]. The XCAP chent provides the means to manipulate 
the data such as user groups, subscription authorization policy, resource Usts, hard state presence infromation, MIME 
objects referenced from the hard state presence information, etc. 

NOTE: In order to be able to manipulate data stored on the XCAP server, the XCAP client has the root directory 
on the XCAP server pre-configured or uses some means to discover it. Discovery mechanisms are outside 
the scope of the present document. 



When the XCAP client intends to manipulate a resource hst, it shall generate an HTTP PUT, HTTP GET or HTTP 
DELETE request in accordance with RFC 2616 [15], RFC 4825 [33] and RFC 4826 [36]. 



When the XCAP server intends to manipulate the subscription authorization policy, it shall generate an HTTP PUT, 
HTTP GET or HTTP DELETE request in accordance with RFC 2616 [15], RFC 4825 [33] and RFC 3025 [35]. 

The XCAP chent may use an HTTP GET in accordance with RFC 2616 [15], RFC 4825 [33] and draft-ietf-simple- 
connmon-policy-caps [41] for fetching of the authorization policy capabilities which the XCAP server supports. 

When the XCAP client intends to authorize a different value of the same presence attribute to different watchers or 
watcher groups, the XCAP client shall authorize a single tuple or person element including one of the different values 
of the same presence attribute to every watcher or watcher groups as specified in RFC 3025 [35]. 

6.3.1 .4 Publishing hard state presence information 

The XCAP chent shall implement RFC 4827 [34] in order to be able to manipulate hard state presence information. 
Hard state presence information uses the same format as soft state information, namely "application/pidf+xml" content 
type as described in RFC 3863 [21] together with any of its extensions. 

When the hard state presence information contains one or more MIME objects to be aggregated with the 
"apphcation/pidf+xml" content type and any of its extensions, the XCAP client shall: 

a) construct as many HTTP URIs as the number of objects to be stored and formulate every HTTP URI according 
to a predefined directory structure; 

NOTE: In order to be able to manipulate data stored on the XCAP server, the XCAP client has the root directory 
on the XCAP server pre-configured or use some means to discover it. Discovery mechanisms are outside 
the scope of the present document. 

b) store the objects on the XCAP server behind the HTTP URl(s) created in the previous step using standard HTTP 
procedures as defined in RFC 2616 [15]; 

c) include every HTTP URI as a value of the corresponding XML element in the published "application/pidf+xml" 
presence document referencing the stored object(s) in the previous step; and 

d) publish the hard state presence information according to RFC 4827 [34]. 



6.3.1.2 



Manipulating a resource list 



6.3.1.3 



Manipulating the subscription authorization policy 
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6.3.2 XCAP server 

6.3.2.1 Introduction 

The XCAP server is a logical function as defined in RFC 4825 [33]. The XCAP server can store data such as user 
groups, subscription authorization policy, resource lists, hard state presence information, MIME objects referenced from 
the hard state presence information, etc. 

6.3.2.2 Resource list manipulation acceptance 

When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for manipulating or fetching a 
resource list, the XCAP server shall first authenticate the request in accordance with 3GPP TS 24.109 [7] and then 
perform authorization. Afterwards the XCAP server shall perform the requested action and generate a response in 
accordance with RFC 2616 [15], RFC 4825 [33] and RFC 4826 [36]. 

6.3.2.3 Subscription authorization policy manipulation acceptance 

When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for manipulating or fetching of 
the subscription authorization poUcy, the XCAP server shall first authenticate the request in accordance with 
3GPP TS 24.109 [7] and then perform authorization. Afterwards the XCAP server shall perform the requested action 
and generate a response in accordance with RFC 2616 1 15J, RFC 4825 [33] and RFC 3025 [35]. 

When the XCAP server receives an HTTP GET request for fetching of the authorization policy capabihties information, 
the XCAP server shall generate a response in accordance with RFC 2616 [15], RFC 4825 [33] and draft-ietf-simple- 
pres-policy-caps [42]. 

6.3.2.4 Publication acceptance of hard state presence information 

When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for publishing, fetching or 
deleting of hard state presence information, the XCAP server shall first authenticate the request in accordance with 
3GPP TS 24.109 [7] and then perform authorization. Afterwards the XCAP server shall: 

a) if the HTTP URI points to a predefined directory reserved for storing MIME objects and the request is an HTTP 
PUT request, replace any existing content referenced by the Request-URI with the content of the request; 

b) if the Request-URI points to an uncreated directory and the request is HTTP PUT, create the directory, store the 
content there and associate the content with the Request-URI. For all requests, i.e. HTTP PUT, HTTP GET and 
HTTP DELETE requests, generate an appropriate response in accordance with RFC 2616 [15]; or 

c) if the HTTP URI points to an XCAP directory and the Application Unique ID (AUID) part of the HTTP URI is 

set to "pidf-manipulation", process the request and generate an appropriate response in accordance with 
RFC 4825 [33], RFC 4827 [34] and RFC 2616 [15]. 



7 Presence information model of tine 3GPP subscriber 

7.1 General 

Void. 

7.2 XML schema definitions 

Void. 

7.3 XIVIL schema descriptions 

Void. 
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Annex A (informative): 

Example signalling flows of presence service operation 
A.1 Scope of signalling flows 

This annex gives examples of signalling flows for the presence service within the IP Multimedia (IM) Core Network 
(CN) subsystem based on the Session Initiation Protocol (SIP) and SIP Events. 

These signalling flows provide detailed signalUng flows, which expand on the overview information flows provided in 
3GPPTS 23.141 [4]. 



A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [8J. The following 
additional considerations apply: 

a) 3GPP TS 24.228 [8] shows separate signalling flows with no configuration hiding between networks, and with 
configuration hiding between networks. There is no presence specific functionality associated with this hiding, 
and therefore such separate signalling flows are not show in the present document; and 

b) 3GPP TS 24.228 [8] does not show the functionality between the S-CSCF and the AS. As the presence service 
depends on the functionality provided by various AS, the signalhng flows between S-CSCF and AS are shown in 
the present document. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [8] subclauses 4.1 and 4.2 applies with the additions 
specified below. 

• rls.homel .net: an RLS in the home network of the watcher; 

• rls.home2.net: an RLS in the home network of the service provider, but not the home network of the watcher; 

• ps.homel .net: a PS in the home network of the publisher; 

• ps.home2.net: a PS in the home network of the service provider, but not in that of the watcher; 

• userl_listl @homel.net: a resource list being subscribed to on a RLS in the home network; 

• user2_Ustl @home2.net: a resource list being subscribed to on a RLS in the home network of the service 
provider, but not the home network of the subscriber; 

• userl_publicl @ho mel.net: presentity being watched, own watcher list; 

• user3_public 1 @home3 .net: presentity being watched. 

As in 3GPP TS 24.228 [8], in order to differentiate between SIP methods and other protocol messages, the message 
name is preceded with the associated protocol for all non-SlP messages. Where the XCAP is used to map an HTTP URI 
to an XML document, the protocol name "XCAP" is used for both the HTTP request and HTTP response. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [8]. 
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However, 3GPP TS 24.228 [8] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [8], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [8] in addition to the material 
shown in the present document. 



The subclause covers the signalling flows that show how watchers can request presence information about a presentity. 
For the routing of the Public Service Identity (PSI) towards the AS, there are two scenarios: 

Subclause A.3.3.2 shows the case where the I-CSCF forwards the SUBSCRIBE request directly to the RLS when the 
RLS is located within the same network. There is another scenario where the I-CSCF forwards the SUBSCRIBE 
request towards the RLS, being involved with the S-CSCF located in the same network, but this scenario is not 
described in the present document. 



A.3 



Signalling flows demonstrating how watchers 
subscribe to presence event notification 



A.3.1 



Introduction 
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A.3.2 Watcher and presentity in different networks, UE in home 
network 



A.3.2. 1 Successful subscription 

Home Network#1 



Home Network#2 



UE 
(Watcher) 



-1. SUBSCRIBE> 



P-GSCF#1 S-GSGF#1 



l-GSGF 



HSS S-GSGF#2 AS(PS) 




-14. 200 (OK) 

-17. NOTIFY 
-18.200 (OK) 



Figure A.3.2.1-1 : Watcher subscribing for presence information 

Figure A.3.2.1-1 shows a watcher subscribing to presence event notification about a presentity. The presentity is in a 
difi'erent IM CN subsystem. The details of the signalhng flows are as follows: 

1 . SUBSCRIBE request (UE (watcher) to P-CSCF) - see example in table A.3.2.1-1 

A watcher agent in a UE wishes to watch a presentity, or certain presence information of the presentity. To 
initiate a subscription, the UE generates a SUBSCRIBE request containing the "presence" event that it wishes 
to be notified of, together with an indication of the length of time this periodic subscription should last and 
the support for partial notification. 
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Table A.3.2.1-1 : SUBSCRIBE request (UE (watcher) to P-CSCF) 



SUBSCRIBE sip :user2_publicl(ahome2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P-Access -Network- Info: 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip : pcscf 1 . visitedl . net : 753 1 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P- Preferred- Identity : <sip : userl_publicl(ahomel . net> 

Privacy: none 

From : <sip : userl_publicl@homel . net> ; tag=31415 

To : <sip : user2_publicl@home2 . net> 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 61 SUBSCRIBE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 
Event : presence 
Expires: 7200 

Accept : application/pidf +xml ; q=0 . 3 , application/pidf -dif f +xml ; q=l 
Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp> 
Content -Length: 



Request-URI: Public user identity whose events the subscriber subscribes to. 

Event: This field is populated with the value "presence" to specify the use of the presence package. 

Accept: This field is populated with the value 'apphcation/pidf+xml' and 'apphcation/pidf-diff+xml', latter 

one with higher preference. 

To: Same as the Request-URI. 

2. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table A.3.2.1-2 

The P-CSCF looks up the serving network information for the pubhc user identity that was stored during the 
registration procedure. The SUBSCRIBE request is forwarded to S-CSCF. A Route header is inserted into 
SUBSCRIBE request. The information for the Route header is taken from the service route determined 
during registration. 

Table A.3.2.1-2: SUBSCRIBE request (P-CSCF to S-CSCF) 



SUBSCRIBE sip:user2_publicl(ahome2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ; branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

P- Access -Network- Info : 
Max-Forwards: 69 

P-Asserted- Identity : <sip : userl_publicl@homel . net> 

P -Charging -Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=023 551024" 

Privacy : 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record-Route : <sip : pcscf 1 . homel . net ; lr> 
From : 
To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 
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3 . Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. In this 

example, no AS is assumed to be involved. 

4. SUBSCRIBE request (S-CSCF to I-CSCF) - see example in table A.3.2.1-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, S-CSCF#1 forwards the SUBSCRIBE request directly to the I-CSCF in the destination 
network. 

Table A.3.2.1-4: SUBSCRIBE (S-CSCF to I-CSCF) 



StJBSCRIBE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/tIDP scscf 1 .homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/tIDP 
pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp; ;branch=z9hG4bKnashds7 
Max- Forwards : 68 

P- Asserted- Identity : <sip : userl_publicl@homel . net> , <tel:+l-212-555-llll> 

P-Charging-Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy : 

Record-Route : < sip : scscf 1 .homel .net; lr>, < sip: pcscf 1 .homel .net; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



5. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message fiows see 3GPP TS 29.228 [10]. 

Table A.3.2.1-5a provides the parameters in the SIP SUBSCRIBE request (flow 4), which are sent to the 
HSS. 



Table A.3.2.1-5a: Cx: User location query procedure (I-CSCF to HSS) 



Message source 
and destination 


Cx: Information 
element name 


Information source in 
SIP SUBSCRIBE 


Description 


I-CSCF to HSS 


User Public Identity 


Request-URI 


This information element indicates 
the public user identity 



Table A.3.2.1-5b provides the parameters sent from the HSS that need to be mapped to the SIP SUBSCRIBE 
request (flow 6) and sent to the S-CSCF. 



Table A.3.2.1-5b: Cx: User location query procedure (HSS to I-CSCF) 



Message source 
and destination 


Cx: Information 

element name 


lUlapping to SIP header 
in SIP SUBSCRIBE 


Description 


HSS to I-CSCF 


S-CSCF name 


Route header field 


This information indicates the serving 
CSCF's name of that user 
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6. SUBSCRIBE request (I-CSCF to S-CSCF) - see example in table A.3.2.1-6 

The I-CSCF forwards the SUBSCRIBE request to the S-CSCF (S-CSCF#2) that wiU handle the termination. 

Table A.3.2.1-6: SUBSCRIBE request (I-CSCF to S-CSCF) 



SUBSCRIBE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
scscf 1 . homel . net ;branch=z9hG4bK351g4 5 . 1 , SIP/2 . 0/UDP 
pcscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 67 
P- Asserted- Identity : 
P-Charging-Vector : 
Privacy : 

Route : <sip : scscf 2 . home2 . net ; lr> 

Record-Route : 

From : 

To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 

path for the subsequent requests. 

7. Evaluation of initial filter criteria 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criteria. For 
sip:user2_public l@home2.net S-CSCF#2 has termination initial filter criteria with Service Point Trigger of 
Method = SUBSCRIBE and Event = "presence" that informs the S-CSCF to route the SUBSCRIBE request 
to the AS ps.home2.net. The S-CSCF#2 has preconfigured information not to create a Record-Route entry for 
this request. 

8. SUBSCRIBE request (S-CSCF to PS) - see example in table A,3.2,l-8 

The S-CSCF forwards the SUBSCRIBE request to the PS. 

Table A.3.2.1-8: SUBSCRIBE request (S-CSCF to PS) 



SUBSCRIBE sip:user2_publicl(Shome2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2. 0/UDP 

icscf2_s .home2 . net ;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bK351g45 .1, SIP/2 . 0/UDP 

pcscf 1 .homel .net ;branch=z9hG4bK24 Of 34 .1, SIP/2 . 0/UDP 

[5 555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: GG 
P- Asserted- Identity : 

P- Charging -Vector : icid-value= "AyretyU0dm+GO2 IrT5tAFrbHLso=02 3 551024 " ; orig- ioi=homel .net 
P-Charging- Function-Addresses : ccf = [5555 : : b99 : cBB : d77 : e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy : 

Route: <sip : ps . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> 

Record-Route : 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

received and populates the identifier of its own network to the originating 
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Inter Operator Identifier (lOI) parameter of this header and removes the 
terminating lOI parameter. 

P-Charging-Function-Addresses: The S-CSCF populates the P-Charging-Function-Addresses header field to be 

passed to the PS. 

9. Authorization of watcher 

The PS performs the necessary authorization checks on the originator to ensure it is allowed to watch the 
presentity. In this example all privacy conditions are met, so the PS sends a 200 (OK) response to the 
S-CSCF. 

In the case where the privacy/authorization checks failes, then a necessary 2xx or 4xx response will be sent to 
the S-CSCF. The selection of the correct response code depends on the presentity's subscription authorization 
policy document. 

10. 200 (OK) response (PS to S-CSCF) - see example in table A.3.2.1-10 

The PS sends the response to S-CSCF#2. 

Table A.3.2.1-10: 200 (OK) response (PS to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1 , SIP/2. 0/UDP 
icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 

scscf 1 .homel .net, •branch=z9hG4bK351g45 .1, SIP/2 . 0/UDP 

pcscf 1 .homel .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" ; orig-ioi=homel .net ; 

term- ioi=home2 . net 

P-Charging- Function-Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : Sec : 9dd] 
Record-Route : 
From : 

To : <sip : user2_publicl@home2 . net> ; tag=151170 

Call-ID: 
CSeq: 
Expires : 

Contact: <sip : ps . home2 . net> 
Content - Length : 



P-Charging- Vector: The PS stores the originating Inter Operator Identifier (lOI) parameter 

received and populates the identifier of its own network to the terminating 
Inter Operator Identifier (101) parameter of this header. 

P-Charging-Function- Addresses: The PS stores the P-Charging-Function-Addresses header field and passes 

this header to the S-CSCF. 

11. 200 (OK) response (S-CSCF to I-CSCF) - see example in table A.3.2.1-11 

S-CSCF#2 forwards the response to I-CSCF#2. 

Table A.3.2.1-11 : 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
scscf 1 .homel .net;branch=z9hG4bK351g45 .1, SIP/2 . 0/UDP 
pcscf 1 .homel. net, •branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

P-Charging-Vector : 

P-Charging-Function-Addresses : 

Record-Route : 

From: 

To: 

Call-ID: 
CSeq: 
Expires : 
Contact : 
Content - Length : 
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P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

received and populates the identifier of its own network to the terminating 
Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the I-CSCF. 

12. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.3.2.1-12 

I-CSCF#2 forwards the response to S-CSCF#1. 



Table A.3.2.1-12: 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP scscf 1 .homel 


net;branch=z9hG4bK351g45 .1, SIP/2 . O/tTDP 


pcscf 1 . homel . net ;branch= 


=z9hG4bK240f34 . 1, SIP/2 . 0/UDP 


[5555: : aaa : bbb : ccc : ddd] 


1357 ; comp=sigcomp;branch=z9hG4bKnashds7 


P- Charging -Vector : 




Record-Route : 




From : 




To: 




Call-ID: 




CSeq: 




Expires : 




Contact : 




Content - Length : 





13. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.2.1-13 

S-CSCF#1 forwards the response to P-CSCF#1. 

Table A.3.2.1-13: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf 1. homel 


.net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP 


[5555 : : aaa : bbb : ccc : ddd] 


: 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 


P-Charging-Vector : icid-value 


="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 


Record-Route : 




From : 




To: 




Call-ID: 




CSeq: 




Expires : 




Contact : 




Content - Length : 





14. 200 (OK) response (P-CSCF to UE) - see example in table A,3,2,l-14 
P-CSCF#1 forwards the response to the watcher agent in the UE. 

Table A.3.2.1-14: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] 


: 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 


Record-Route : <sip : orig@scscf 1 .homel .net 


; lr>, < sip : pcscf 1 .homel .net : 7531; Ir ; comp=sigcomp> 


From : 




To: 




Call-ID: 




CSeq: 




Expires : 




Contact : 




Content - Length : 





15. NOTIFY request (PS to S-CSCF) - see example in table A.3.2.1-15 

As soon as the PS sends a 200 (OK) response to accept the subscription, it sends a NOTIFY request with the 
current state of the presentity's presence information that the watcher has subscribed and been authorized to. 
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The NOTIFY request is sent to S-CSCF#1. Based on the Accept header field of the SUBSCRIBE request, the 
PS decides to use partial notification to provide changes of presence information. 



Table A.3.2.1-15: NOTIFY request (PS to S-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/tIDP ps . home2 . net ;branch=z9hG4bK348923 . 1 




Max- Foirwairds : 7 




P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=12 3 551024 " ; 


orig-ioi=home2 .net 


P- Charging -Function- Addresses : ccf=[5555::b99:c88:d7 7:e66]; ccf=[5555: 


:a55 :b44 :c33 :d22] ; 


ecf=[5555: :lff:2ee: 3dd: 4ee] ; ecf = [5555 : : 6aa : 7bb: Sec : 9dd] 




Route: <sip : scscf 1 . homel . net ; lr> , <sip : pcscf 1 . homel . net ; lr> 




From: <sip:user2 publicl@home2 . net> ; tag=151170 




To: <sip:userl publiclOhomel . net> ; tag=31415 




Call -ID: b8 9rjhnedlrf jf Islj4 0a2 2 2 




CSeq: 42 NOTIFY 




Subscription-State: active ; expires=72 00 




ILvdlL . U J. t: to dlL^ t: 




Contact: <sip : ps . home2 . net> 




Content -Type : application/pidf -dif f +xml 




Content -Length : (...) 




<?xml version= " 1 . " encoding= "UTF- 8 " ? > 




<dif f :pidf - f ull xmlns= "urn : ietf : params : xml : ns : pidf " 




xmlns : dif f= "urn : ietf : params : xml : ns : pidf -dif f " 




xmlns : rpid= "urn : iet f : params : xml : ns : pidf : rpid" 




xmlns : dm= "urn : ietf : params : xml : ns : pidf : data-model " 




xmlns : pcp= "urn : ietf : params : xml : ns : pidf : caps " 




xmlns : c= "urn : ietf : params : xml : ns : pidf : cipid" 




entity="pres : user2_publicl@home2 .net" 




version= " 1 " > 




< tuple id="a8 9 8a. 6 72 3 64 762364"> 




<status> 




<basic>open< /basio 




</status> 




<rpid: class >sip</ rpid: class > 




<rpid : privacyxtext /></ rpid : privacy> 




<rpid : status- icon>http : //example . com/ ~user2/ icon . gif < /rpid : status -icon> 


<pcp : servcaps> 




<pcp : videof alse< /pep : video 




<pcp : audio>true< /pep : audio 




</pcp : servcaps> 




<contact priority= " . 8 " >sip : user2 publicl(ahome2 .net</contact> 




<note xml : lang= "en" >Don ' t Disturb Please ! </note> 




<note xml : lang= " f r " >Ne derangez pas, s'il vous plait</note> 




<timestamp>2003-08-27Tll :49 : 2 9Z</timestamp> 




</tuple> 




<tuple id="jklhgf 9788934774 .78" > 




<status> 




<basic>open< /basio 




</status> 




<rpid : class >ass is tant< /rpid : class > 




<rpid : relat ionshipxrpid : assistant />< /rpid : relationship> 




<contact priority="l . 0">tel : +1 -2 12 -555 -2222</contact> 




<note xml : lang= "en" >She ' s my secretary</note> 




<timestamp>2 003-08-27Tll : 49 : 29Z</timestamp> 




</tuple> 




<dm:person id="s438"> 




<rpid: c las s>presentity</ rpid: class> 




<c : homepage >http : / /example . com/~user2</c : homepage > 




<c : card>http : //example . com/~user2/card. vcd</c : card> 




<rpid : activitiesxrpid : meeting/ >< /rpid : activities> 




<rpid: place -type until = "2003-08-27T17 : 30 : OOZ" xrpid : of f ice/ ></rpid : place- type> 


< /dm : person> 




</diff :pidf-full> 





P-Charging- Vector: The PS populates the icid parameter with a globally unique identifier and 

adds the identifier of its own network to the originating Inter Operator 
Identifier (lOI) parameter of this header. 
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P-Charging-Function-Addresses: The PS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

Content-Type: Set to the preferred value of the Accept header received in the SUBSCRIBE 

request. 

The message body in the NOTIFY request that carries the presence information of the presentity is formed as 
indicated in RFC 3863 [21], RFC 4480 [26], draft-ietf-simple-prescaps-ext [25], RFC 4482 [32] draft-ietf- 
simple-partial-notify [24] and RFC 4479 [44]. 

16. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.3.2.1-16 

The S-CSCF#1 forwards the NOTIFY request to P-CSCF#1. 

Table A.3.2.1-16: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 

ps . home2 .net ;branch=z9hG4bK348923 . 1 
Max- Forwards : 69 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123 551024" 
P-Charging-Function-Addresses : 
Privacy : 

Record-Route : <sip : scscf 1 . homel . net ; lr> 
Route : sip : <pcscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content -Type : 
Content - Length : 

(...) 



P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

of this header and removes the parameter from this header. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function- Addresses header field and 

passes this header to the P-CSCF. 

17. NOTIFY request (P-CSCF to UE) - see example in table A.3.2.1-17 

The P-CSCF forwards the NOTIFY request to the watcher in the UE. 



Table A.3.2.1-17: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555: : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp 


SIP/2 . 


Via: SIP/2. 0/UDP pcscfl .homel .net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 


scscf 1 .homel .net ;branch=z9hG4bK351g45 . 1 , SIP/2 


0/UDP ps .home2 .net ;branch=z9hG4bK34 8923 . 1 


Max- Forwards : 68 




Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl 


homel . net : 7531 ; Ir ; comp=sigcomp> 


Privacy : 




From: 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Event : 




Contact : 




Content -Type : 




Content - Length : 




(...) 





18. 200 (OK) response (UE to P-CSCF) - see example in table A.3.2.1-18 
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The UE generates a 200 (OK) response to the NOTIFY request. 

Table A.3.2.1-18: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .homel .net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP ps .home2 .net ;branch=z9hG4bK34 8923 . 1 
P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 

Content -Length: 



19. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.3.2.1-19 

The P-CSCF forwards the 200 (OK) response to S-CSCF#1. 

Table A.3.2.1-19: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 

ps .home2 .net ;branch=z9hG4bK34 8923 . 1 
P-Access-Network-Inf o : 
From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



20. 200 (OK) response (S-CSCF to P-S) - see example in table A.3.2.1-20 

S-CSCF#2 forwards the 200 (OK) response to the PS. 

Table A.3.2.1-20: 200 (OK) response (S-CSCF to PS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ps .home2 .net;branch=z9hG4bK348923 . 1 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 
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A.3.3 Watcher subscribing to resource list, UE in visited network 

A.3.3.1 Watcher subscribing to his own resource list, UE in visited network 
Successful subscription 



Visited Networl< 



UE 



P-CSCF 



LSUBSCRiBE 



8. 200 (OK) 



11. NOTiFY 



12. 200 (OK) 



18. NOTiFY 
19.200 (OK) 



S-CSCF 



2. SUBSCRiBE 



3. Evaiuation of 
initiai fiiter criteria 



7. 200 (OK) 



10. NOTil=Y 



13. 200 (OK) 



17. NOTiFY 



20. 200 (OK) 



Home Network of UE 



4. SUBSCRiBE 



6. 200 (OK) 



9. NOTiFY 



14. 200 (OK) 



16. NOTiFY 



21. 200 (OK) 



AS(RLS) 



5. Watciier 
Authorisation 



15. Subscriptions and 
notifications on 
presence event 



Figure A.3.3.1 -1 : Watcher subscribing to resource list 



Figure A.3.3. 1-1 shows a watcher subscribing to resource Ust event notification. The details of the signalhng flows are 
as follows: 

1 . SUBSCRIBE request (UE to P-CSCF) - see example in table A.3.3.1-1 

A watcher agent in a UE wishes to watch a number of presentities, or certain presence information of these 
presentities. The list of presentities are identified by a SIP URI. In order to initiate a subscription to the RLS, 
the UE generates a SUBSCRIBE request indicating support for "eventUst", together with an indication of the 
length of time this periodic subscription should last. 
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Table A.3.3.1-1 : SUBSCRIBE request (UE to P-CSCF) 



SUBSCRIBE sip :userl_listl(ahomel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
Max-Forwards: 70 

P-Access -Network- Info: 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip : pcscf 1 . visitedl . net : 753 1 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P- Preferred- Identity : <sip : userl_publicl(ahomel . net> 

Privacy: none 

From : <sip : userl_publicl@homel . net> ; tag=31415 

To: <sip : userl_listl@homel . net> 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 123 SUBSCRIBE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 
Event : presence 
Supported: eventlist 
Expires: 7200 

Accept: application/pidf +xml , application/rlmi+xml , multipart/related 
Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 
Content -Length: 



Request-URI: SIP URI of the resource list representing the collection of public user identities whose events the 

subscriber subscribes to. 

Event: This field is populated with the value "presence" to specify the use of the presence package. 

Accept: This field is populated with the value "application/pidf+xml", "application/rlmi+xml" and 

"multipart/related" indicating that the UE supports both body types for the eventlist extension 
additionally to PIDF. 

Supported: This field is populated with the value "eventlist" to specify the support for the eventlist extension. 
To: Same as the Request-URI. 

2. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table A.3.3.1-2 

The P-CSCF looks up the serving network information for the pubUc user identity that was stored during the 
registration procedure. The SUBSCRIBE request is forwarded to S-CSCF#1. A Route header is inserted into 
SUBSCRIBE request. The information for the Route header is taken from the service route determined 
during registration. 

Table A.3.3.1-2: SUBSCRIBE request (P-CSCF to S-CSCF) 



SUBSCRIBE sip:userl_listl(Shomel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK120f 34 . 1 , SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc ; ddd] ; 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 

P- Access -Network- Info : 

Route : <sip : origOscscf 1 . homel . net ; lr> 

Max-Forwards: 69 

P- Asserted- Identity : <sip : userl_publicl@homel . net > 

P-Charging- Vector : icid-value= "AyretyUOdm+602 IrT5tAFrbHLso=223 551024 " 
Privacy : 

Record-Route : <sip : pcscf 1 .visitedl .net ; lr> 
Route : <sip : scscf 1 .homel .net; lr> 
From : 
To: 

Call-ID: 
CSeq: 
Event : 
Supported : 
Expires : 
Accept : 
Contact : 
Content - Length : 



3 . Evaluation of initial filter criteria 
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The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. Assuming 
that sip:userl_listl @homel.net is a statically created PSI, sip:userl_listl @homel.net is included in the 
service profile as part of an originating initial Filter Criteria with Service Trigger Point of Method = 
SUBSCRIBE AND Supported = "eventUst" AND Request-URI = sip:userl_Ustl@homel.net that informs 
the S-CSCF to route the SUBSCRIBE request to the AS sip:rls.homel.net. 

If there is no initial filter criteria for this PSI (sip:userl_listl@homel.net), the assumption is that the PSI is a 
sub domain-based PSI. The procedure defined in RFC 3263 [18] with DNS NAPTR and SRV queries may 
then be used to get the IP address of the AS homel.net. 

4. SUBSCRIBE request (S-CSCF to RLS) - see example in table A.3.3.1-4 

The S-CSCF forwards the SUBSCRIBE request to the RLS. 

Table A.3.3.1-4: SUBSCRIBE request (S-CSCF to RLS) 



SUBSCRIBE sip:userl_listl(ahomel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK344a65 . 1 , SIP/2. O/tTDP 
pcscfl .visitedl.net ;branch=z9hG4bK12 Of 34 .1, SIP/2 . 0/UDP 
[55 55 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 

Max-Forwards: 68 

P- Access -Network- Info : 

P- Asserted- Identity : <sip : userl_publicl(ahomel .net>, <tel:+l-212-555-llll> 

P- Charging -Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=223551024 " ; orig- ioi=homel .net 
P-Charging- Function-Addresses : ccf = [5555 : : b99 : c88 : d7 7 : e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy : 

Record- Route : <sip : origOscscf 1 . homel . net ; lr> , <sip : pcscfl . visitedl . net ; lr> 

Route: <sip : rls . homel . net ; lr> , <sip : origOscscfl . homel . net ; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Supported : 
Expires : 
Accept : 
Contact : 
Content - Length : 



P-Charglng- Vector: The S-CSCF populates the identifier of its own network to the originating 

Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF populates the P-Charging-Function-Addresses header field to be 

passed to the RLS. 

5 . Authorization of watcher 

The RLS performs the necessary authorization checks on the originator to ensure that he/she is authorized to 
use the resource list. In this example this condition has been met, so the PS sends a 200 (OK) response to the 
S-CSCF. If the previous condition failed, then a 403 (Forbidden) response would be sent to the S-CSCF. 

6. 200 (OK) response (RLS to S-CSCF) - see example in table A.3.3.1-6 

The RLS sends the response to the S-CSCF. 
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Table A.3.3.1-6: 200 (OK) response (RLS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK344ae5 . 1 , SIP/2. 0/UDP 
pcscf 1 . visitedl .net ;branch=z9hG4bK12 0f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKehuef dam 

P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223 551024" ; orig-ioi=homel .net ; 
term- ioi=homel . net 

Record-Route : 

From : 

To : <sip : userl_listl@homel . net> ; tag=151170 

Call-ID: 
CSeq: 

Require: eventlist 
Expires : 
Contact : 

Content -Length: 



P-Charging- Vector: The RLS stores the terminating Inter Operator Identifier (lOI) parameter and populates the 
identifier of its own network to the terminating Inter Operator Identifier (lOI) parameter of 
this header. 

7. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.3.1-7 

The S-CSCF forwards the response to the P-CSCF. 

Table A.3.3.1-7: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/tIDP pcscf 1 .visitedl . net ;branch=z9hG4bK120f 34 . 1 , SIP/2. 0/tIDP 

[5555 : : aaa: bbb: ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
P- Charging- Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=223 551024" 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Expires : 
Contact : 
Content - Length : 



P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter received. 
8. 200 (OK) response (P-CSCF to UE) - see example in table A.3.3.1-8 

The P-CSCF forwards the response to the watcher agent in the UE. 



Table A.3.3.1-8: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 






Via: SIP/2. O/UDP [5555 :: aaa : bbb : ccc : ddd] 


: 1357 ; comp= 


=sigcomp;branch=z9hG4bKehuef dam 


Record-Route : <sip : origOscscf 1 .homel .net 


;lr>, <sip 


pcscf 1 .visitedl .net : 7531 ,- Ir ; comp=sigcomp> 


From: 






To: 






Call-ID: 






CSeq: 






Require : 






Expires : 






Contact : 






Content - Length : 







9. NOTIFY request (RLS to S-CSCF) - see example in table A.3.3.1-9 

The RLS generates a NOTIFY request including the RLMI document as a result of the SUBSCRIBE request. 
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Table A.3.3.1-9 NOTIFY request (RLS to S-CSCF) 



NOTIFY sip : [5555 :: aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP rls .homel .net ;branch=z9hG4bK240f 34 . 1 




Max-Forwards: 70 




P-Charging- Vector : icid-value= "AyretyUOdm+602 IrT5tAFrbHLso=3 2 3 551024 " ; 


orig-ioi=homel .net 


P- Charging -Function- Addresses : ccf=[5555::b99:c88:d7 7:e66]; ccf=[5555: 


:a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 




Route : <sip:scscfl. homel . net ; lr> , <sip : pcscf 1 . visitedl . net ; lr> 




From: <sip:userl listl@homel . net> ; tag=151170 




To: <sip:userl publicl@homel . net> ; tag=31415 




Call -ID: b8 9rjhnedlrf jflslj40a222 




CSeq: 89 NOTIFY 




Subscription-State : active ,- expires=7200 




Require: eventlist 




Event: presence 




Contact: <sip : rls . homel . net > 




Content -Type : application/rlmi+xml ; charset= "UTF- 8 " 




Content - Length : 




<?xml version^ " 1 . " encoding= "UTF- 8 " ? > 




<list xmlns= "urn : ietf : params : xml : ns : rmli " 




uri= " sip : userl listiohomel .net" version="l" fullState="true" > 




<resource uri= "pres : user2 publicl@home2 . net " > 




< name >Ko vacs Janos</name> 




<instance id= "hqzsuxtf yq" state="active" cid= " ZvSvkzOrls . homel . 


net"/> 


</resource> 




<resource uri = "pres : user3 publicl(ahome3 . net " > 




<name>Szabo Bela</name> 




<instance id="aakdsjklsa" state="active" cid="HJjbssk@rls .homel 


.net"/> 


</resource> 




</list> 





P-Charging- Vector: The RLS inserts this header and populates the icid parameters with a globally 

unique value and adds the identifier of its own network to the originating 
Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The RLS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

10. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.3.3.1-10 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 

Table A.3.3.1-10: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

rls . homel . net ;branch=z9hG4bK240f 34 . 1 
Max-Forwards: 69 

P-Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323 551024" 

P-Charging-Function-Addresses : 

Route : <sip : pcscf 1 .visitedl .net ; lr> 

Record-Route : <sip : scscf 1 .homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 

Subscription-State : 
Require : 
Event : 
Contact : 
Content - Length : 

(...) 



P-Charging- Vector: 



P-Charging-Function-Addresses: 



The S-CSCF stores onginatmg Inter Operator Identifier (lOI) parameter 
received. 

The S-CSCF stores the P-Charging-Function-Addresses header field and 
passes this header to the P-CSCF. 



ETSI 



3GPP TS 24.141 version 8.2.0 Release 8 37 ETSI TS 124 141 V8.2.0 (2008-10) 

1 1 . NOTIFY request (P-CSCF to UE) - see example in table A.3.3.1-11 

The P-CSCF forwards the NOTIFY request to the watcher in the UE. 



Table A.3.3.1-11 : NOTIFY request (P-CSCF to UE) 



WOT T FY '=i"ir) - FRRRR - • • Inlnln • rm • ririri^ •1'^R7* rrimn— •=! "i drrimn 

±>IVh' J- J- ±r ± O • L^^^^* a^^^* i-/ A-/ A-/ • \^ \^ \^ • ^.^k^k^ J m -i- J ^ 1 f \^ \_/1LLLh' — O -L y \^ V./ILLLh' 


SIP/2 . 


via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 


scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


0/UDP 


rls . homel .net ;branch=z9hG4bK24 0f 34 . 1 




Max - Forwards : 68 




Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl. 


visitedl .net : 7531; Ir ; comp=sigcomp> 


From : 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Require : 




Event : 




Contact : 




Content - Length : 




(...) 





12. 200 (OK) response (UE to P-CSCF) - see example in table A,3.3.1-12 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.3.3.1-12: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscfl .visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 


scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


0/UDP 


rls .homel .net ;branch=z9hG4bK24 0f 34 . 1 




P-Access-Network-Inf o : 3GPP-tJTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


Frora: 




To: 




Call-ID: 




CSeq: 




Content - Length : 





13. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.3.3.1-13 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.3.3.1-13: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

rls .homel .net ;branch=z9hG4bK24 0f 34 . 1 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323 551024" 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



14. 200 (OK) response (S-CSCF to RLS) - see example in table A.3.3.1-14 

The S-CSCF#2 forwards the response to the RLS in the home network of the UE. 
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Table A.3.3.1-14: 200 (OK) response (S-CSCF to RLS) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP rls . homel . net ; branch=z9hG4bK240f 34 . 1 




P- Access -Network- Info : 




P-Charging-Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=323551024 " 


orig-ioi=homel . net ; 


term-ioi=homel .net 




From : 




To: 




Call-ID: 




CSeq: 




Content - Length : 





P-Charging- Vector: The S-CSCF inserts the originating Inter Operator Identifier (lOI) parameter received and 
populates the identifier of its own network to the terminating Inter Operator Identifier (lOI) 
parameter of this header. 

15. Subscriptions and notifications on presence event package 

After the RLS generated a NOTIFY request to inform the UE about the subscription state, the RLS generates 
the necessary SUBSCRIBE requests to the presentities present in the resource list as described in 
subclause A.3.4.1. As soon as it receives NOTIFY request(s) about a state change in one or more presentities, 
it generates a NOTIFY request. 
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16. NOTIFY request (RLS to S-CSCF) - see example in table A.3.3.1-16 

The RLS copies the body of the incoming NOTIFY request(s) into the body of the outgoing NOTIFY request 
using MIME type multipart/related. Further notification sent by the RLS may contain either the full or the 
partial set of presence information (only the presence information that has changed since the last notification) 
as described in RFC 4662 [22]. 

In this example it is assumed that the RLS has received two NOTIFY requests from presentities 
sip:user2_pubhcl @home2.net and sip:user3_pubhcl @home3.net before generating the NOTIFY request in 
table A.3.3.1-16 to the UE. 



Table A.3.3.1-16 NOTIFY request (RLS to S-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 




vXci: 0-Lir/^,U/UJJir J_±o. IlOIllc X . lie U / iJX. 0.110-11= Z yilort JJJ\.^ ft U U rt . X 




Max- Fo3rwa3rds : 70 




P- Chairging- Vector : ic id-value = " Ay3retyU0dTn-i-6O2 l3rT5 tAF3rbHLso=42 3 551024" ; 


orig- ioi=homel . net 


F- i^nairgxrig- r uncuxon- Aaaxesses : ccr=L->->->->: :Jjyy:coo:a//:efDoj ; ccr=L->->->->: 


: as 3 : jj^^ : c j j : o.zz j ; 


Q^-F recce. •i-F-F.OQQ.'^i-ii-i.yiQQi . Q^-F recce, .^r^^. tki-i . . Q/^/^i 
ecr= loooo t t ITT I zee : Jaa : 4ee j ; ecr=L->->->->^J baa : /dd : hcc : yaaj 




Route : < sip : scscf 1 . honiel . net ; l3r> , < sip :pcscfl .visitedl . net ; l3r> 




Froni : < sip : useirl 1 ist l@hoTnel . net > ; tag=15 117 




To : <sip : use3rl_publicl . honiel . net > ; tag=3 1415 




L-axx — xu: jjoyxj nneuxr r j rxsxj 4ua^^^ 








Subscrxpt ion- State : active ; expi3res=5 




Require : eventlist 




Event: presence 




Contact : < sip : rl s . honiel . net > 




Content - Type : niultipart/ related ; type= " appl icat ion/rlmi-i-xnil " ; 




start= <nAYxAiii@r±s . riotnei . net > ; DOunciary= " bUUBt w / iibLV iitggUPebz " 




Content -Length: (...) 




C niTD-FTATTT Cn\TJ ^ r^r^llT^aCrr 

— DUUJsxVv / J_ioL- V J_iUyy UFeo Z 




Content -Transfer- Encoding : binary 




l^OIlt-cIlt- XU : <I1A 1 XtiCilSfl X o . IlOTllc X . lie U > 




Content -Type : application/ rlnii-Hxnil ; charset= "UTF- 8 " 




< rxnix versxon= x.u encoQxng= uir o .> 




<list xmlns="urn : ietf :params : xml : ns : rmli " 




uri=" sip : userl listl@homel . net" version=" 1" f ullState=" true" > 




< re source uri= "pres : user2_publicl@hoTne2 . net " > 




<naTne>Kovacs iJanos< /naTne> 




<. XllE> L-CLllL-C: Xlul — 11<J Zi O 1 ^-VM OUCLUC — CLV^I LVC L>X<ul. — ZjVO V JS-ZiliyX X O . IIUILLCX . 


net " / > 


< / re s our c e > 




< resource uri= "pres : user 3 publ icl@honie3 . net " > 




<nanie>Szabo Bela< / name > 




< instance id="aakds jklsa" state=" active" cid="HJjbssk@rls .homel 


.net'7> 


</resource> 




</list> 




- - 5 OUBf W7LSCVLtggUPe5 z 




Content-Transfer-Encoding : binary 




Content -ID : <ZvSvkz@rls . homel . net> 




Content -Type : appl icat ion/pidf+xml ;charset="UTF-8" 




<?xml version="l . 0" encoding="UTF-8" ?> 




<presence xmlns="urn: ietf :params :xml :ns :pidf " 




xmlns : rpid="urn : ietf :params :xml :ns :pidf :rpid" 




xmlns :dm= "urn: ietf :params :xml :ns :pidf :data-model" 




xmlns :pcp="urn: ietf :params :xml :ns :pidf : caps" 




xmlns : c="urn : ietf :params : xml : ns :pidf : cipid" 




entity="pres : user2_publicl@home2 .net" > 




<tuple id="a8098a. 672364762364 "> 




<status> 




<basic>open</basic> 




</status> 




<rpid: class>sip</rpid: class > 




<rpid : privacyxtext/ ></ rpid : privacy> 




<rpid : status - icon>http : / / example . com/ ~user2/icon . gif </rpid : status -icon> 


<pcp : servcaps > 




<pcp : videof alse</pcp : video 




<pcp : audio>true</pcp : audio 




</pcp : servcaps> 




<contact priority="0 . 8 " >sip : user2_publicl@home2 . net</contact> 
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<note xml : lang="en" >Don ' t Disturb Please ! </note> 
<note xml : lang=" f r" >Ne derangez pas, s'il vous plait</note> 
<timestamp>2 003-08-27Tll : 49 : 29Z</timestamp> 
</tuple> 

<tuple id="jklhgf 9788934774 .78" > 
<status> 

<basic>open</basic> 
</status> 

<rpid: class >assistant</rpid : class > 

<rpid : relationshipxrpid : assistant/ ></rpid : relationship> 
<contact priority="l . " >tel : +1-212- 555 -2222</contact> 
<note xml : lang="en" >She ' s my secretary</note> 
<timestamp>2 003-08-27Tll : 49 : 29Z</timestamp> 
</tuple> 

<dm:person> 

<rpid: class >presentity</rpid : class > 
<c : homepage >http : //example . com/~user2</c : homepage > 
<c : card>http : //example . com/ ~user2/ card . vcd< /c : card> 
<rpid : act ivi ties xrpid : meeting/ ></rpid : activities> 

<rpid: place -type until="2003-08-27T17 : 30 : OOZ" xrpid : of f ice/ ></rpid : place- type> 
</dm:person> 

</presence> 

- - 5 OUBf W7LSCVLtggUPe5 z 

Content-Transfer-Encoding : binary 

Content - ID : <ZvSvkz(apres . example . com> 

Content -Type : applicat ion/pidf +xml ; charset= "UTF- 8 " 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

<presence xmlns= "urn : let f : params : xml : ns : pidf " 

xmlns : rpid= "urn : let f : params : xml : ns : pidf : rpid" 
xmlns : dm= "urn : ietf : params : xml : ns : pidf : data-model " 
xmlns :pcp="urn: ietf : params :xml :ns :pidf : caps" 
entity="pres :user3_publicl@home3 .net" > 

< tuple id= "h7833hjkk. dsaj f jdsaf " > 

<status> 

<basic>closed</basic> 

</status> 

<rpid : c las s>sip</ rpid : class > 

<rpid : privacyxrpid : text/ ></rpid:privacy> 

<pcp : servcaps> 

<pcp : video false< /pep : video 
<pcp : audio>true< /pep : audio> 

</pcp : servcaps> 

< contact prior ity= " . 8 " >sip : user3_publicl(ahome3 . net< /contact > 
<note xml : lang= "en" >Don ' t Disturb Please ! </note> 
<note xml : lang= "hu" >Senki se merjen zavarni ! </note> 
<timestamp>2003-08-27Tll :48 : 5 9Z</timestamp> 
</tuple> 

<tuple id= "sajdhdsahjh75wcb774 . 78" > 

<status> 

<basic>open</basic> 

</status> 

<rpid : class>supervisor</rpid : class > 

<rpid : relationshipxrpid : supervisor/ x/rpid : relationship> 
<contact priority="l . 0">tel : +1 - 858 -2 04 - 914 l</contact> 
<note xml : lang= "en" >He ' s my supervisor</note> 
<timestamp>2 003 -08-27T11 : 48 : 59Z</timestamp> 

</tuple> 

<dm : person> 

<c : homepage >http : //example . com/~user3</ c : homepage > 
<c : card>http : / / example . com/ -user 3 /card . vcd</c : card> 
<rpid: class>presentity</rpid: class> 

<rpid : act ivi ties xrpid : vacation/ x /rpid : activities> 

<rpid: place -type until="2003-09-10T17 : 30 : OOZ" xrpid : ship/ x/rpid : place- type> 

</dm : person> 

</presence> 
- - 5 OUBf W7LSCVLtggUPe5 z - - 
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P-Charging- Vector: The RLS inserts this header and populates the icid parameters with a globally 

unique value and adds the identifier of its own network to the originating 
Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The RLS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

Content-Type: Set to the value of the Accept: header received in the SUBSCRIBE request. 

The message body in the NOTIFY request that carries the presence information of the presentity is formed as 
indicated in RFC 4662 [22], RFC 4479 [44], RFC 4480 [26], RFC 4482 [32] and draft-ietf-simple-prescaps- 
ext [25]. 

17. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.3.3.1-17 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 

Table A.3.3.1-17: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
rls . homel . net ;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 69 

P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423 551024" 

P-Charging-Function-Addresses : 

Route : <sip : pcscf 1 . visitedl . net ; lr> 

Record-Route : <sip : scscf 1 .homel .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 

Subscription-State : 
Require : 
Event : 
Contact : 
Content Type : 
Content - Length : 

(...) 



P-Charging- Vector: The RLS stores the originating Inter Operator Identifier (lOl) parameter 

received. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the P-CSCF. 

18. NOTIFY request (P-CSCF to UE) - see example in table A.3.3.1-18 

The P-CSCF forwards the NOTIFY request to the watcher in the UE. 



Table A.3.3.1-18: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp 


SIP/2 . 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=240f 34 . 1 


SIP/2 . 0/UDP 


scscf 1 . homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 


0/UDP 


rls . homel . net ;branch=z9hG4bK240f 34 . 1 




Max - Forwards : 68 




Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl 


visitedl .net : 7531; Ir ; comp=sigcomp> 


From : 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Require : 




Event : 




Content-Type : 




Content - Length : 




(...) 
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19. 200 (OK) response (UE to P-CSCF) - see example in table A.3.3.1-19 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 



Table A.3.3.1-19: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 


scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


0/UDP 


rls . homel .net ;branch=z9hG4bK240f 34 . 1 




P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content - Length : 





20. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.3.3.1-20 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.3.3.1-20: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

rls .homel .net ;branch=z9hG4bK24 0f 34 . 1 
P-Access-Network-Inf o : 

P -Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423 551024" 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



21. 200 (OK) response (S-CSCF to RLS) - see example in table A.3.3.1-21 

The S-CSCF#2 forwards the response to the RLS in the home network of the UE. 

Table A.3.3.1-21 : 200 (OK) response (S-CSCF to RLS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP rls .homel .net;branch=z9hG4bK240f 34 . 1 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423 551024" ; orig-ioi=homel .net ; 
term-ioi=homel .net 

From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The S-CSCF inserts the originating Inter Operator Identifier (lOI) parameter received and 
populates the identifier of its own network to the terminating Inter Operator Identifier (lOI) 
parameter of this header. 
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A.3.3.2 Watcher subscribing to a resource list, UE in visited network 
successful subscription 



Visited Network 



UE iHome Network 



UE 



P-CSCF S-CSCF#1 



l-CSCF 



1. SUBSCRIBE 



2. SUBSCRIBE 



3. Evaluation of 
Initial filter 
criteria 



10. 200 (OK) 



1 1 . 200 (OK) 



13. NOTIFY 



14. NOTIFY 



15. 200 (OK) 



16. 200 (OK) 



20. NOTIFY 



21. NOTIFY 



22. 200 (OK) 



23. 200 (OK) 



4. SUBSCRIBE 



9. 200 (OK) 



Home Network of AS 

HSS 



5. Cx: PS! location query 



6. SUBSCRIBE 



8. 203 (OK) 



12. NOTIFY 



17. 200 (OK) 



19. NOTIFY 



24. 200 (OK) 



AS(RLS) 



7. Watcfier 
Autfiorlsatlon 



18. 

Subscriptions 
and notifications 

on presence 
event package 



Figure A.3.3.2-1 Watcher subscribing to resource list 
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Figure A. 3. 3. 2-1 shows a watcher subscribing to resource hst event notification. The details of the signalhng flows are 
as follows: 

1 . SUBSCRIBE request (UE to P-CSCF) - see example in table A.3.3.2-1 

A watcher agent in a UE wishes to watch a number of presentities, or certain presence information of these 
presentities. The list of presentities are identified by a SIP URI. In order to initiate a subscription to the RLS, 
the UE generates a SUBSCRIBE request indicating support for "eventhst", together with an indication of the 
length of time this periodic subscription should last. 



Table A.3.3.2-1 : SUBSCRIBE request (UE to P-CSCF) 



SUBSCRIBE sip:user2_listl(ahome2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuefdam 
Max-Forwards: 70 

P-Access -Network- Info: 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip :pcscf 1 . visitedl .net : 7531 ; Ir; comp=sigcomp> , <sip : origOscscf 1 .homel .net; lr> 

P- Preferred- Identity : <sip : userl_publicl@homel . net> 

Privacy : none 

From : <sip : userl_publicl@homel . net > ; tag=31415 

To: <sip : user2_list lOhomel . net > 

Call -ID: b89rjhnedlrf jf Islj4 0a222 

CSeq: 123 SUBSCRIBE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l- 96 ; spi-c=98765432 ; spi-s=87654321; port- 

c=8642; port-s=7531 
Event : presence 
Supported: eventlist 
Expires: 7200 

Accept: application/pidf +xml , application/rlmi+xml , multipart/related 
Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 
Content - Length : 



Request-URI: SIP URI of the resource list representing the collection of pubhc user identities whose events the 

subscriber subscribes to. 

Event: This field is populated with the value "presence" to specify the use of the presence package. 

Accept: This field is populated with the value "application/pidf+xml", "appIication/rlmi+xml" and 

"multipart/related" indicating that the UE supports the eventlist extension additionally to PIDF. 

Supported: This field is populated with the value "eventlist" to specify the support for the eventlist extension. 

To: Same as the Request-URI. 
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2. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table A.3.3.2-2 

The P-CSCF looks up the serving network information for the pubHc user identity that was stored during the 
registration procedure. The SUBSCRIBE request is forwarded to S-CSCF#1. A Route header is inserted into 
SUBSCRIBE request. The information for the Route header is taken from the service route determined 
during registration. 

Table A.3.3.2-2: SUBSCRIBE request (P-CSCF to S-CSCF) 



StJBSCRIBE sip:user2_listl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK120f 34 . 1 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
P-Access -Network- Info : 

Route : <sip : orig@scscf 1 .homel .net ; lr> 
Max- Forwards : 69 

P- Asserted- Identity: < sip : user l_publicl@homel .net> 

P -Charging -Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=023 551024" 
Privacy : 

Record-Route : < sip : pcscf 1 .visitedl .net; lr> 

Route : <sip : scscf 1 .homel .net; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Supported : 
Expires : 
Accept : 
Contact : 
Content - Length : 



3 . Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. In this 
example, no AS is assumed to be involved. 

4. SUBSCRIBE request (S-CSCF to I-CSCF) - see example in table A.3.3.2-4 

S-CSCF#1 perfornas an analysis of the destination address. As the destination address points to a resource 
that is in a different network as the S-CSCF, the S-CSCF sends the request to the I-CSCF of home2.net. 



Table A.3.3.2-4: SUBSCRIBE request (S-CSCF to I-CSCF) 



SUBSCRIBE sip:user2 listl@home2.net SIP/2.0 




Via: SIP/2. O/tTDP scscf 1 .homel .net;branch=z9hG4bK344a65 . 1, SIP/2. O/tTDP 




pcscf 1 .visitedl .net ;branch=z9hG4bK120f 34 . 1 , SIP/2 . 0/UDP 




[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 




Max - Forwards : 68 




P-Asserted- Identity : <sip:userl publiclOhomel . net> , <tel : +l-212-555-llll> 


P -Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; 


orig-ioi=homel .net 


P-Charging-Function-Addresses : ccf = [5555 : :b99 :c88 :d77 :e66] ; ccf = [5555 : 


a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : Sec : 9dd] 




Privacy : 




Record-Route : <orig@sip : scscf 1 . homel . net ; lr> , <sip ; pcscf 1 .visitedl . net 


lr> 


From: 




To: 




Call-ID: 




CSeq: 




Event : 




Supported : 




Expires : 




Accept : 




Contact : 




Content - Length : 
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5. PSI location query 

The I-CSCF sends a query to the HSS to find the RLS where sip:user2_Ustl @home2.net is hosted. The HSS 
responds with the address of the RLS. 

For detailed message flows see 3GPP TS 29.228 [10]. 

Table A.3.3.2-5a provides the parameters in the SIP SUBSCRIBE request (flow 4), which are sent to the 
HSS. 



Table A.3.3.2-5a Cx: User location query procedure (I-CSCF to HSS) 



Message source & 
destination 


Cx: Information 
element name 


Information source 
in SIP SUBSCRIBE 


Description 


I-CSCF to HSS 


User Public 
Identity 


Request-URI: 


This information 
element Indicates the 
PSI of the RLS 



Table A.3.3.2-5b provides the parameters sent from the HSS that need to be mapped to SIP SUBSCRIBE 
(flow 6) and sent to S-CSCF. 



Table A.3.3.2-5b Cx: User location query procedure (HSS to I-CSCF) 



lUlessage source & 
destination 


Cx: Information 
element name 


IVIapping to SIP 
header in SIP 
SUBSCRIBE 


Description 


HSS to I-CSCF 


S-CSCF name 


Route header field 


This information indicates 
the address of the RLS 



6. SUBSCRIBE request (I-CSCF to RLS) - see example in table A.3.3.2-6 

The I-CSCF forwards the SUBSCRIBE request to the RLS. 

Table A.3.3.2-6: SUBSCRIBE request (I-CSCF to S-CSCF) 



StJBSCRIBE sip:user2_listl@home2 .net SIP/2.0 

Via: SIP/2. O/tTDP icscf2_s .home2 .net;branch=z9hG4bK871yl2 . 1, SIP/2.0/tJDP 
scscf 1 . homel .net ;branch=z9hG4bK344a65 . 1 , SIP/2 . 0/UDP 
pcscf 1 . visitedl .net ;branch=z9hG4bK120f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 

Max - Forwards : 67 

P- Asserted- Identity: 

P-Charging-Vector : 

Privacy : 

Record-Route : 

Route: <sip : rls . home2 . net ; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Supported : 
Expires : 
Accept : 
Contact : 
Content - Length : 



7. Authorization of watcher 

The RLS performs the necessary authorization checks on the originator to ensure that he/she is authorized to 
use the resource list. In this example this condition has been met, so the PS sends a 200 (OK) response to the 
S-CSCF. If the previous condition failed, then a 403 (Forbidden) response would be sent to the S-CSCF. 
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8. 200 (OK) response (RLS to I-CSCF) - see example in table A.3.3.2-8 

The RLS sends the response to the S-CSCF. 

Table A.3.3.2-8: 200 (OK) response (RLS to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 

scscf 1 . homel . net ;branch=z9hG4bK344a65 . 1 , SIP/2 . 0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK12 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig-ioi=homel .net ; 

term- ioi=home2 . net 

P- Charging -Function- Addresses : ccf=[5555::b99:c88:d7 7:e66]; ccf=[5555::a55:b44:c33:d22]; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : 6aa : 7bb : Sec : 9dd] 
Record-Route : 
From : 

To: <sip:user2_listl@home2 . net> ; tag=151170 

Call-ID: 
CSeq: 

Require: eventlist 
Expires : 

Contact: <sip : rls .home2 .net> 
Content - Length : 



P-Charging- Vector: The RLS stores the originating Inter Operator Identifier (lOI) parameter and 

populates the identifier of its own network to the terminating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The RLS stores the P-Charging-Function-Addresses header field and passes 

this header to the I-CSCF. 

9. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.3.3.2-9 

The I-CSCF forwards the response to the S-CSCF. 

Table A.3.3.2-9: 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK344aG5 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl. net; branch=z9hG4bK12 Of 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 

P-Charging-Vector : 

Record-Route : 

From : 

To: 

Call-ID: 
CSeq: 
Require : 
Expires : 
Contact : 

Content - Length : 



P-Charging- Vector: The RLS stores the header and passes this header to the S-CSCF. 
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10. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.3.2-10 

The S-CSCF forwards the response to the P-CSCF. 

Table A.3.3.2-10: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK120f 34 . 1 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
P -Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Expires : 
Contact : 
Content - Length : 



P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter. 
11. 200 (OK) response (P-CSCF to UE) - see example in table A.3.3.2-11 

The P-CSCF forwards the response to the watcher agent in the UE. 



Table A.3.3.2-11 : 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] 


: 1357 ; comp=sigcomp ; branch=z9hG4bKehuef dam 


Record-Route : <sip : origOscscf 1 . homel . net 


; lr>, <sip :pcscf 1 .homel .net : 7531; Ir ; comp=sigcomp> 


From : 




To: 




Call-ID: 




CSeq: 




Require : 




Expires : 




Contact : 




Content - Length : 





ETSI 



3GPP TS 24.141 version 8.2.0 Release 8 49 ETSI TS 124 141 V8.2.0 (2008-10) 

12. NOTIFY request (RLS to S-CSCF) - see example in table A.3.3.2-12 

The RLS generates a NOTIFY request including the RLMI document as a result of the SUBSCRIBE request. 
Table A.3.3.2-12: NOTIFY request (RLS to S-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP rls .home2 .net;branch=z9hG4bK240f 34 . 1 
Max - Forwards : 7 

P -Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123 551024" ; orig-ioi=homel .net 
Route : <sip : scscf 1 . homel . net ; lr> , <sip : pcscf 1 . visitedl . net ; lr> 

From : <sip : user2_list lohomel . net > ; tag=151170 
To : <sip : userl_publicl . homel . net> ; tag=3 1415 
Call -ID: b8 9rjhnedlrf jflslj4 0a222 
CSeq: 8 9 NOTIFY 

Subscription-State : active ;expires=5000 

Require: eventlist 

Event : presence 

Contact: <sip : rls . homel . net> 

Content -Type : application/rlmi+xml ; charset="UTF-8 " 
Content -Length : (...) 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

<list xmlns= "urn : ietf : params : xml : ns : rmli " 

uri= " sip : userl_list lohomel . net " version= " 1 " f ullState= " true " > 
<resource uri= "pres : user2_publicl@home2 . net" > 
< name >Ko vacs Janos</name> 

<instance id= "hqzsuxtf yq" state="active" cid="ZvSvkz@rls .home2 .net"/> 

</resource> 

<resource uri= "pres : user3_publicl@home2 . net" > 
<name>Szabo Bela</name> 

<instance id="aakdsjklsa" state="active" cid="HJjbssk@rls .home2 .net"/> 
</resource> 
</list> 



P-Charging- Vector: The RLS populates the icid parameter with a globally unique value and populates the 

identifier of its own network to the originating Inter Operator Identifier (lOl) parameter of 
this header. 

13. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.3.3.2-13 

The S-CSCF#1 forwards the NOTIFY request to the P-CSCF. 



Table A.3.3.2-13: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 




Via: SIP/2. O/tTDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 


O/tTDP 


rls .home2 .net;branch=z9hG4bK240f 34 . 1 




P- Charging- Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=123 551024" 


P-Charging-Function-Addresses : ccf=[5555: : b99 : c88 : d77 : e66] ; ccf= 


[5555 : :a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : Sec : 9dd] 




Max- Forwards : 69 




Record-Route : <sip : scscf 1 .homel .net; lr> 




Route : < sip : pcscf 1 .visitedl .net; lr> 




From: 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Require : 




Event : 




Contact : 




Content-Type : 




Content - Length : 




(...) 





P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter. 

P-Charging-Function-Addresses: The RLS populates the P-Charging-Function-Addresses header field to be 

passed to the I-CSCF. 
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14. NOTIFY request (P-CSCF to UE) - see example in table A.3.3.2-14 

The P-CSCF forwards the NOTIFY request to the watcher in the UE. 



Table A.3.3.2-14: NOTIFY request (P-CSCF to UE) 



WOT T FY '=i"i'n - FRRRR - • • Inlnln • rm • ririri^ •1'^R7*r' nmn — •=! "i cir nmn 


SIP/2 . 


via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 


scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


0/UDP 


rls . home2 .net ;branch=z9hG4bK24 0f 34 . 1 




Max - Forwards : 68 




Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl. 


homel . net : 7531 ; Ir ; comp=sigcomp> 


From : 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Require : 




Event : Contact : 




Cont ent - Type : 




Content - Length : 




(...) 





15. 200 (OK) response (UE to P-CSCF) - see example in table A.3.3.2-15 

The UE acknowledges the NOTIFY request with a 200 (OK) to the P-CSCF. 

Table A.3.3.2-15: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 


scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


0/UDP 


rls .home2 .net ;branch=z9hG4bK24 0f 34 . 1 




P-Access-Network-Inf o : 3GPP-tJTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content - Length : 





16. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.3.3.2-16 

The P-CSCF forwards the 200 (OK) response to the S-CSCF#1. 

Table A.3.3.2-16: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

rls .home2 .net ;branch=z9hG4bK24 0f 34 . 1 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyUOdm+602IrT5tAFrbHLso=123 551024" 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 
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17. 200 (OK) response (S-CSCF to RLS) - see example in table A.3.3.2-17 

The S-CSCF#1 forwards the response to the RLS in the home network of the UE. 

Table A.3.3.2-17: 200 (OK) response (S-CSCF to RLS) 



SIP/2.0 200 OK 

Via: SP/2.0/UDP rls . home2 . net ;branch=z9hG4bK240f 34 . 1 

P -Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123 551024 " ; orig-ioi=homel .net : 
term-ioi=homel .net 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The S-CSCF inserts the originating Inter Operator Identifier (lOI) parameter received and 
populates the identifier of its own network to the terminating Inter Operator Identifier (lOI) 
parameter of this header. 

18. Subscriptions and notifications on presence event package 

After the RLS generated a 200 (OK) response to the SUBSCRIBE request from the UE, it generates the 
necessary SUBSCRIBE requests to the presentities present in the resource list as described in 
subclause A.3.4.1. As soon as it receives NOTIFY request(s) about a state change in one or more presentities, 
it generates a NOTIFY request. 
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19. NOTIFY request (RLS to S-CSCF) - see example in table A.3.3.2-19 

The RLS copies the body of the incoming NOTIFY request(s) into the body of the outgoing NOTIFY request 
using MIME type multipart/related. Further notification sent by the RLS contain may contain either the full 
or the partial set of presence information (only the presence information that has changed since the last 
notification) as described in RFC 4662 [22]. 

In this example it is assumed that the RLS receives two NOTIFY requests from presentities 
sip:user2_pubhcl @home2.net and sip:user3_pubhcl @home3.net before generating the NOTIFY request in 
subclause A.3.3.2-23 to the UE. 

Table A.3.3.2-19: NOTIFY request (RLS to S-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP rls .home2 .net;branch=z9hG4bK240f 34 . 1 
Max- Forwards : 70 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223 551024" ; orig-ioi=homel .net 

Route : <sip : scscf 1 .homel .net; lr>, <sip :pcscf 1 . visitedl .net; lr> 

From: <sip : user2_listl@homel . net> ; tag=151170 

To : <sip :userl_publicl .homel .net>; tag=31415 

Call -ID: b89rjhnedlrf jflslj4 0a222 

CSeq: 89 NOTIFY 

Subscription-State : active ;expires=5000 

Require: eventlist 

Event : presence 

Contact: <sip : rls . home2 . net> 

Content-Type : multipart/related;type="application/rlmi+xml" ; 

start = " <nXYxAE@rl s . home2 . net > " ; boundary= " 5 OUBf W7LSCVLtggUPe5 z " 
Content -Length: (...) 

- - 5 OUBf W7LSCVLtggUPe5 z 
Content-Transfer-Encoding : binary 
Content -ID : <nXYxAE@rls .home2 .net> 

Content -Type : application/rlmi+xml ; charset="UTF-8 " 

<?xml version="l . 0" encoding="UTF-8 " ?> 

<list xmlns="urn : ietf :params : xml : ns : rmli" 

uri=" sip : userl_listl@homel . net" version=" 1" f ullState=" true" > 
<resource uri="pres :user2_publicl@home2 .net" > 
<name>Kovacs Janos</name> 

<instance id="hqzsuxtfyq" state=" active" cid="ZvSvkz®rls .home2 .net"/> 
</resource> 

<resource uri="pres :user3_publicl@home3 .net"> 
<name>Szabo Bela</name> 

<instance id="aakdsjklsa" state="active" cid="HJjbssk@rls .home2 .net"/> 
</resource> 
</list> 

- - 5 OUBf W7LSCVLtggUPe5 z 
Content-Transfer-Encoding : binary 
Content - ID : < ZvSvkzOrl s . home2 . net > 

Content -Type : application/pidf +xml ;charset="UTF-8" 

<?xml version="l . 0" encoding="UTF-8 " ?> 

<presence xmlns="urn: ietf :params :xml :ns :pidf " 

xmlns : rpid="urn : ietf :params :xml :ns :pidf : rpid" 
xmlns : dm= "urn: ietf :params :xml :ns :pidf : data-model" 
xmlns :pcp=" urn: ietf :params :xml :ns :pidf caps" 
xmlns : c="urn : ietf :params : xml : ns :pidf : cipid" 
entity="pres :user2_publicl@home2 .net" > 

<tuple id="a8098a. 672364762364 "> 
<status> 

<basic>open</basic> 
</status> 

<rpid: class >sip</ rpid: class > 

<rpid : privacyxtext/x/rpid : privacy> 

<rpid : status - icon>http : //example . com/ ~user2/ icon . gif </rpid : status -icon> 

<pcp : servcaps> 

<pcp : video>f alse< /pep : video 
<pcp : audio >t rue < /pep : audio 
< /pep : serveaps > 

< cent act priority= " . 8 " >sip : user2_publiel(ahome2 . net < /contact > 

<note xml : lang= "en" >Don ' t Disturb Please ! </note> 

<note xml : lang="f r " >Ne derangez pas, s'il vous plait</note> 
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<timestamp>2 003-08-27Tll : 49 : 29Z</timestamp> 
</tuple> 

<tuple id="jklhgf 9788934774 .78" > 
<status> 

<basic>open</basic> 
</status> 

<rp : class >assistant</rp : class > 

<rpid : relationshipxrpid : assistant/ ></rpid : relationship> 
<contact priority="l . 0" >tel : +1-212- 555 -2222</contact> 
<note xml : lang="en" >She ' s my secretary</note> 
<timestamp>2 003-08-27Tll : 49 : 29Z</timestamp> 
</tuple> 

<dm:person> 

<rpid: class >presentity</rpid : class > 
<c : homepage >http : //example . com/~user2</c : homepage> 
<c : card>http : / /example . com/~user2/card . vcd< /c : card> 
<rpid : act ivi ties xrpid : meeting/ ></rpid : activities> 

<rpid: place -type until="2003-08-27T17 : 30 : OOZ" xrpid : of f ice/ ></rpid: place -type> 
</dm:person> 

</presence> 

--50UBfW7LSCVLtggUPe5z 

Content-Transfer-Encoding : binary 

Content- ID : <ZvSvkz@pres . example . com> 

Content -Type : application/pidf +xml ; charset= "UTF-8 " 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

<presence xmlns= "urn : let f : params : xml : ns : pidf " 

xmlns : rpid= "urn : ietf : params : xml : ns : pidf : rpid" 
xmlns : dm= "urn : ietf : params : xml : ns : pidf : data-model " 
xmlns :pcp="urn: ietf : params :xml :ns :pidf : caps" 
entity="pres :user3_publicl@home3 .net" > 

<tuple id="h7833hjkk.dsajf jdsaf "> 
<status> 

<basic>closed</basic> 

</ status> 

<rpid : c las s>sip</ rpid : class > 

<rpid : privacyxrpid : text/ ></rpid:privacy> 

<pcp : servcaps> 

<pcp : video false< /pep : video 
<pcp : audio>true< /pep : audio> 
< / pep : servcaps > 

< contact prior ity= " . 8 " >sip : user3_publicl@home3 . net< /contact > 
<note xml : lang= "en" >Don ' t Disturb Please ! </note> 
<note xml : lang= "hu" >Senki se merjen zavarni ! </note> 
<timestamp>2003-08-27Tll :48 : 5 9Z</timestamp> 
</tuple> 

<tuple id= " sa j dhdsahj h75wcb774 . 78 " > 

<status> 

<basic>open</basic> 

</status> 

<rpid : class>supervisor</rpid : class > 

<rpid : relationshipxrpid : supervisor/ x/rpid : relationship> 
<contact priority="l . 0">tel : +1 - 858 -2 04 - 9141</contact> 
<note xml : lang= "en" >He ' s my supervisor</note> 
<timestamp>2 003-08-27Tll : 48 : 59Z</timestamp> 

</tuple> 

<dm : person> 

<c : homepage >http : //example . com/~user3</c : homepage > 
<c : card>http : / / example . com/ -user 3 / card . vcd</c : card> 
<rpid: c las s>presentity</ rpid: class> 

<rpid : act ivi ties xrpid : vacation/ x /rpid : activities> 

<rpid: place -type until="2003-09-10T17 : 30 : OOZ" xrpid : ship/ x/rpid : place- type> 

</dm : person> 

</presence> 
- - 5 OUBf W7LSCVLtggUPe5 z - - 



ETSI 



3GPP TS 24.141 version 8.2.0 Release 8 



54 



ETSI TS 124 141 V8.2.0 (2008-10) 



P-Charging- Vector: The RLS populates the icid parameter with a globally unique value and populates the 

identifier of its own network to the originating Inter Operator Identifier (lOI) parameter of 
this header. 

Content-Type: Set to the value of the Accept: header received in the SUBSCRIBE request. 

The message body in the NOTIFY request that carries the presence information of the presentity is formed as 
indicated in RFC 4662 [22], RFC 4479 [44], RFC 4480 [26], RFC 4482 [32] and draft-ietf-simple-prescaps- 
ext [25]. 

20. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.3.3.2-20 

The S-CSCF#1 forwards the NOTIFY request to the P-CSCF. 



Table A.3.3.2-20: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/tJDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 


0/UDP 


rls .home2 .net ;branch=z9hG4bK24 0f 34 . 1 




Max- Forwards : 69 




P- Charging- Vector : icid-value="AyretyUOdm+602IrT5tAFrbHLso=223 551024" 


P-Charging-Function-Addresses : ccf=[5555: : b99 : c88 : d77 : e66] ; ccf= 


[5555 : :a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 




Route : <sip:pcscf 1 . visitedl .net; lr> 




Record-Route : <sip : scscf 1 .homel .net; lr> 




From: 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Require : 




Event : 




Contact : 




Content - Type : 




Content - Length : 




(...) 





P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter 

received. 

P-Charging-Function-Addresses: The S-CSCF populates the P-Charging-Function-Addresses header field to be 

passed to the P-CSCF. 

21 . NOTIFY request (P-CSCF to UE) - see example in table A.3.3.2-21 

The P-CSCF forwards the NOTIFY request to the watcher in the UE. 



Table A.3.3.2-21 : NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/tJDP pcscfl .visitedl .net;branch=240f 34 . 1 , SIP/2. 0/UDP 




scscf 1 .homel .net ;branch=z9hG4bK332b23 . lSIP/2 . 0/UDP rls .home2 .net 


branch=z9hG4bK240f 34 . 1 


Max - Forwards : 68 




Record-Route : < sip : scscf 1 .homel .net; lr>, < sip : pcscfl .homel .net : 7531 ; Ir 


comp=sigcomp> 


From: 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Require : 




Event : 




Contact : 




Content -Type : 




Content - Length : 




(...) 





22. 200 (OK) response (UE to P-CSCF) - see example in table A.3.3.2-22 
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The UE acknowledges the NOTIFY request with a 200 (OK) to the P-CSCF. 

Table A.3.3.2-22: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, SIP/2. 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bK332b23 . lSIP/2 . 0/UDP rls .home2 .net ;branch=z9hG4bK24 0f 34 . 1 
P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 

Content -Length: 



23 . 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.3.3.2-23 

The P-CSCF forwards the 200 (OK) response to the S-CSCF#1. 

Table A.3.3.2-23: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

rls . home2 . net ;branch=z9hG4bK24 0f 34 . 1 
P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223 551024" , orig-ioi=homl .net , 

term- ioi=visitedl .net 
P-Access-Network-Inf o : 
From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



24. 200 (OK) response (S-CSCF to RLS) - see example in table A.3.3.2-24 

The S-CSCF#2 forwards the response to the RLS in the home network of the UE. 

Table A.3.3.2-24: 200 (OK) response (S-CSCF to RLS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP rls . home2 . net ;branch=z9hG4bK240f 34 . 1 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223 551024" , orig-ioi=homl .net ; 
term-ioi=homel . net 

From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The S-CSCF inserts the originating Inter Operator Identifier (lOI) parameter received and 
populates the identifier of its own network to the originating Inter Operator Identifier (lOl) 
parameter of this header. 
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A.3.4 RLS subscribing to presentities in different network 
A.3.4.1 Successful subscription 



List server 

AS(RLS) S-CSCF#1 

1. SUBSCRIBE 



l-CSCF 



Presentity Home Network 

HSS S-CSCF#2 



2. Evaluation of 
initial filter 
criteria 



3. SUBSCRIBE 



4. Cx: User location query 



5. SUBSCRIBE 



10. 200 (OK) 



11 . 200 (OK) 



12. 200 (OK) 



14. NOTIFY 



15. 200 (OK) 



13. NOTIFY 



AS(PS) 



16. 200 (OK) 



6. Evaluation of 

initial filter 
criteria 



7. SUBSCRIBE 



8. Watcfier 
authorisation 



9. 200 (OK) 



Figure A.3.4.1 -1 RLS subscribing to presentities in different networl( 



Figure A.3.4. 1-1 shows the RLS subscribing to presence event notification about a presentity. The presentity is in a 
different IM CN subsystem. The details of the signalUng flows are as follows: 



1 . SUBSCRIBE request (RLS to S-CSCF) - see example in table A.3.4,1-1 

The RLS resolves the watcher's resource address (the address is received according to subclause A.3.3) and 
subscribes to presence event notification at all the presentities that are represented by the resource list SIP 
URL The home network of these presentities can be different or in the same network, as the RLS. In this 
example only a single subscription is shown where the home network of the presentity is another network. 
Subscriptions to other presentities follow a similar procedure. To initiate a subscription, the RLS generates a 
SUBSCRIBE request containing the "presence" event that it wishes to be notified of, together with an 
indication of the length of time this periodic subscription should last. The RLS sends the SUBSCRIBE 
request to the S-CSCF of "sip:userl_publicl @homel.net" (S-CSCF#1). The address of S-CSCF#1 is either 
remembered from previous transactions (when "sip:userl_pubhcl@homel.net" has subscribed for the 
resource list) or queried by the RLS using the Sh interface. 
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Table A.3.4.1-1 SUBSCRIBE request (RLS to S-CSCF) 



SUBSCRIBE sip:user2 publicl(ahome2 .net SIP/2.0 




Via: SIP/2. 0/UDP rls . homel . net ; branch=z9hG4bKehuef dam 




Max-Forwards: 70 




Route : <sip:scscfl. homel . net ; lr> 




P-Asserted-Identity : <sip:userl publiciohomel .net> 




P-Charging-Vector : icid-value= "AyretyUOdm+602 IrTStAFrbHLso 


=323551024" ; orig-ioi=homel .net 


P- Charging -Function- Addresses : ccf=[5555::b99:c88:d7 7:e66] 


; ccf= [5555 : :a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 


9dd] 


From: <sip:userl publiciahomel . net> ; tag=31415 




To: <sip:user2 publicl@home2 .net> 




Call -ID: q9 8 7a9a8 7g0 8 7abgf VqygVag 




CSeq: 123 SUBSCRIBE 




Event : presence 




Expires: 7200 




Accept: application/pidf +xml 




Contact: <sip : rls .homel .net> 




Content -Length: 





Request-URI: Public user identity whose events the RLS subscribes to. 

P-Charging- Vector: The RLS populates the icid parameter with a new globally unique value and 

populates the originating Inter Operator Identifier (lOl) parameter with the 
identifier of its own network of RLS. 

P-Charging-Function-Addresses: The RLS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

To: Same as the Request-URI. 

Event: This field is populated with the value "presence" to specify the use of the 

presence package. 

Accept: This field is populated with the value "application/pidf+xml". 

2. Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. In this 
example, no AS is assumed to be involved. 

3 . SUBSCRIBE request (S-CSCF to I-CSCF) - see example in table A.3.4.1-3 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. S-CSCF#1 forwards the request to the I-CSCF. 

Table A.3.4.1-3 SUBSCRIBE request (S-CSCF to I-CSCF) 



SUBSCRIBE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel .net;branch=z9hG4bKehuehjgt, SIP/2. 0/UDP 

rls . homel .net ;branch=z9hG4bKehuef dam 
Max- Forwards : 69 

Record-Route : <sip : orig@scscf 1 . homel . net ; lr> 

P- Asserted- Identity: 

P-Charging-Vector : 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter received. 
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4. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the presentity. The HSS responds with the 
address of the current S-CSCF for the presentity. 

For detailed message flows see 3GPP TS 29.228 [10]. 

Table A.3.4.1-4a provides the parameters in the SIP SUBSCRIBE request (flow 3), which are sent to the 
HSS. 



Table A.3.4.1-4a: Cx: User location query procedure (I-CSCF to HSS) 



Message source 
and destination 


Cx: Information 
element name 


Information source 
in SIP SUBSCRIBE 


Description 


I-CSCF to HSS 


User Public 
Identity 


Request-URI 


This information element Indicates 
the public user identity 



Table A.3.4.1-4b provides the parameters sent from the HSS that need to be mapped to SIP SUBSCRIBE 
request (flow 5) and sent to the S-CSCF. 



Table A.3.4.1-4b: Cx: User location query procedure (HSS to I-CSCF) 



IVIessage source 
and destination 


Cx: Information 
element name 


Mapping to SIP header 
in SIP SUBSCRIBE 


Description 


HSS to I-CSCF 


S-CSCF name 


Route header field 


This information indicates the serving 
CSCF's name of that user 



5 . SUBSCRIBE request (I-CSCF to S-CSCF) - see example in table A.3.4.1-5 

The I-CSCF forwards the SUBSCRIBE request to the S-CSCF#2 that will handle the termination. 

Table A.3.4.1-5: SUBSCRIBE request (I-CSCF to S-CSCF) 



StJBSCRIBE sip:user2_publicl@home2 .net SIP/2.0 




Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bKj 5hgrt2o, 


SIP/2 . 0/tJDP 


scscf 1 . homel .net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP 




rls . homel . net ;branch=z9hG4bKehuef dam 




Max-Forwards: 68 




P- Asserted- Identity: 




P-Charging-Vector : icid-value= "AyretytJ0dm+6O2IrT5tAFrbHLso= 


323551024" ; orig-ioi=homel .net; 


Route : <sip : scscf 2 . home2 . net ; lr> 




Record-Route : 




From: 




To: 




Call-ID: 




CSeq: 




Event : 




Expires : 




Accept : 




Contact : 




Content-Length : 





6. Evaluation of initial filter criteria 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criteria. For 
sip:user2_publicl @home2.net the S-CSCF has Termination initial Filter Criteria with Service Point Trigger 
of Method = SUBSCRIBE AND Event = "presence" that informs the S-CSCF to route the SUBSCRIBE 
request to the AS ps.home2.net. The S-CSCF#2 has preconfigured information not to create a Record-Route 
entry for this request. 
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7. SUBSCRIBE request (S-CSCF to PS) - see example in table A.3.4.1-7 

The S-CSCF#2 forwards the SUBSCRIBE request to the PS. 



Table A.3.4.1-7 SUBSCRIBE request (S-CSCF to PS) 



SUBSCRIBE sip:user2_publicl@home2 .net SIP/2.0 




Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK344a65 . 1, SIP/2. 


0/UDP 


icscf2 s . home2 . net ;branch=z9hG4bKj 5hgrt2o, SIP/2. 0/UDP 




scscf 1 .homel . net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP 




rls . homel . net ;branch=z9hG4bKehuef dam 




Max-Forwards: 67 




P- Asserted- Identity : 




P-Charging-Vector : 




P- Charging -Function- Addresses : ccf=[5555::b99:c88:d7 7:e66]; ccf= 


[5555: :a55:b44:c33:d22] ; 


ecf=[5555: :lff:2ee: 3dd: 4ee] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 




Route: <sip : ps . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> 




Record-Route : <sip : origOscscf 1 . homel . net ; lr> 




From : 




To: 




Call-ID: 




CSeq: 




Event : 




Expires : 




Accept : 




Contact : 




Content - Length : 





P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

received and populates the identifier of its own network to the originating 
Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF populates the P-Charging-Function-Addresses header field to be 

passed to the PS. 

8. Authorization of watcher 

The PS performs the necessary authorization checks on the originator to ensure it is allowed to watch the 
presentity. In this example all privacy conditions are met, so the PS sends a 200 (OK) response to the 
S-CSCF. 

In the case where the privacy/authorization checks fails, then a necessary 2xx or 4xx response will be sent to 
the S-CSCF. The selection of the correct response code depends on the presentity's subscription authorization 
policy document. 

9. 200 (OK) response (PS to S-CSCF) - see example in table A.3.4.1-9 

The PS sends the response to S-CSCF#2. 



Table A.3.4.1-9: 200 (OK) response (PS to S-CSCF) 



SIP/2.0 200 OK 






Via: SIP/2. 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK344a65 . 1 , SIP/2. 


0/UDP 




icscf2 s .home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2. 0/UDP 






scscf 1 .homel . net ;branch=z9hG4bKehuehj gt , SIP/2 . 0/UDP 






rls . homel . net ;branch=z9hG4bKehuef dam 






P-Charging- Vector : icid-value= "AyretyU0dm+GO2 IrT5tAFrbHLso=3 2 3 551024 " ; 


orig- 


ioi=home2 . net : term- ioi=home2 . net 






P-Charging-Function-Addresses : ccf = [5555 : : b99 : cBB : d77 : e66] ; ccf= 


[5555 : 


:a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 






Record-Route : 






From : 






To : <sip : user2_publicl@home2 . net> ; tag=15117 






Call-ID: 






CSeq: 






Expires : 






Contact: <sip :ps .home2 .net ; lr> 






Content - Length : 
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P-Charging- Vector: The PS stores the originating Inter Operator Identifier (lOI) parameter 

received and populates the identifier of its own network to the terminating 
Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The PS stores the P-Charging-Function-Addresses header field and passes 

this header to the S-CSCF. 

10. 200 (OK) response (S-CSCF to I-CSCF) - see example in table A.3.4.1-10 

S-CSCF#2 forwards the response to the I-CSCF. 

Table A.3.4.1-10: 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bKj 5hgrt2o, SIP/2. O/tTDP 
scscf 1 . homel . net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP 
rls . homel . net ;branch=z9hG4bKehuef dam 

P-Charging-Vector : 

P-Charging-Function-Addresses : 

Record-Route : 

From: 

To: 

Call-ID: 
CSeq: 
Expires : 
Contact : 
Content - Length : 



P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter 

received and populates the identifier of its own network to the terminating 
Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the I-CSCF. 

11. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.3.4.1-11 

The I-CSCF forwards the response to S-CSCF#1. 

Table A.3.4.1-1 1 : 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/tIDP scscf 1 . homel . net ;branch=z9hG4bKehuehjgt , SIP/2. 0/tIDP 

rls . homel .net ;branch=z9hG4bKehuef dam 
P-Charging-Vector : 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Expires : 
Contact : 
Content - Length : 



12. 200 (OK) response (S-CSCF to RLS) - see example in table A.3.4.1-12 

S-CSCF#1 forwards the response to the RLS. 
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Table A.3.4.1-12: 200 (OK) response (S-CSCF to RLS) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP rls . homel . net ; branch=z9hG4bKehuef dam 




P-Charging-Vector : 




P-Charging- Function-Addresses : ccf = [5555: :b99:c88:d7 7 


e66] ; ccf= [5555 : : a55 : b44 : c33 : d22] ; 


ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: :6aa:7bb 


8cc:9dd] 


Record-Route : 




From: 




To: 




Call-ID: 




CSeq: 




Expires : 




Contact : 




Content - Length : 





P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter 

received and populates the identifier of its own network to the terminating 
Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the RLS. 
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13. NOTIFY request (PS to S-CSCF) - see example in table A.3.4.1-13 

As soon as the PS sends a 200 (OK) response to accept the subscription, it sends a NOTIFY request with the 
current state of the presentity's presence information that the watcher has subscribed and been authorized to. 
The NOTIFY request is sent to S-CSCF#1 . 



Table A.3.4.1-13: NOTIFY request (PS to S-CSCF) 



NOTIFY sip: rls.homel.net SIP/2.0 




Via: SIP/2. 0/UDP ps . home2 . net ;branch=z9hG4bK348923 . 1 




M3.X— F'0]fW3.]fd.S I VO 








P - "rni nn - Vf^r*"!" rtr" • H r" H H -\r^ 1 11*= — " Zi'\/r'Pi1~'\/TTnHTn-i-fin9 Tt^TRI" Zi'P'K'ViH'T.cin — 4. 9 "^t^t^l 094." • rrrHn-'in'i 

£r ^IICL-L ^ _L11^ VC^Lh^-L- • _L _L \jL V CL -L LLC — "-Y W L- V U U ^^ILL^ Q V_y ^ J. J. ^ L'f^.C J- l^STLi—l O LJ — T±^.J ^^_LU^T± ^ L^ _L^_L 


— Vi om ps 9 n ps I" 

— llLn/LLLC^ . lie L- 


From: <sip : userl_publicl@home2 . net >; tag=15 1170 




To : <sip :rls .homel .net>; tag=31415 












QiiViar^T"! ttI~ n on — C3"l~?j"l~f3 • ?j/~""l~n "irfi • fivr^ n T^fs a — 79 

O LiiJ O J- 1 L 1.^11 OL.a.L.C • O-V^l LvC^ C J^-JJ -L J- CO — / ^ U U 








^k.^llL'W.^L'* -1- • O • ll^LLLC^ • lie L- 




(""on 1" P^Ti 1" — "PvTiP^ • aTiTiT "i r'a 1" "i on / n "i "F -i-"yTnn 
^k.^iiL'diL' X vlh/c • ^ -L -L ^ ^ L- -L ^.^11/ -L ^^-1- ~.^lLL_L 




Content - Length : (...) 




O-vml irpa'K'a "i on — "1 0" panr^oHnnrT— " TTPTT — Q " "? ^ 
<« ; .^ILLJ. V C J- & XUli — X . U CllL>UlulXliy — UJ..r O i ^ 




^T^T"Q c? d n d "VTTi n nc!~"ii T^n . n Q ^ ^ . ^ tti a . "vm H . n a . n ^ " 




xTtilns 1 3rpid= " um i ie t f i pa.3ra.Tns i xnil ;ns ipldf 1 3rpid " 




xTtilns I clni= um i iett i paranis i xnil i ns i pidt i Ciata~nioclel 




"vmH n a • ni^n — " 1 1 ■K'n • n p3"I~"F •t^jj v^Jina • ■vm 1 ^na 'T^n H"F • /"■^j'na" 

.A.1LLJ.110 . — LLJ- 11.XCL.J- .^a.X 0.1110 . .A.1LLX .llo .^XIulX . ^^0.^0 




VTTI Hna ./^— "ii T^n . n o ^ ^ . a tti c . "vm H . n a . n ^ . n n " 

.^ILLXllO . L> — U.X 11. XCL.X .LfCLX CLlLLO . .^ILLX .llO .UXlulX .L> XL) X LI 




entity="pres : user2_publicl@home2 .net " > 




<'-t-nn1(=' ■i(i-"aflnQfta fi79Tfi47fi9Tfi4"-> 




<statu.s > 




^ Via an /^"^onpin^ / Via an /"""^ 

^i-'O.B X^^ .^IJ^^Cll^ / iJO.OJ-\^^ 




</statu.s> 




<3rpid : class >sip< / 3rpid : class > 




<^ T"T) "i • TIT""! "^T"?? r'V'^^l'P^vt" / "ix^ / T~n "i • Ttyi tt"?? r* 

^ X u _L kij. . M J — V CT.^ y ^ L- c./^ L- / ^ 1 X u _L ^ . M J — L V CT.^ y ^ 




<x^XU. c>L.a.LU.c> XQ^Ull^Il L up • / / c.Ji.a.llipx c . t^Ulll/ ~U.ocx^ / XQ^Ull .yxx< / x^XU. oLa.LU.o XQ^U11> 




^^V^^ . OCX VV^O.^O-' 




<pcp : video>f al se< /pep : video > 




<pcp : audio>true</pcp : audio> 




</pcp : servcaps> 




^ rrin T^cf" nT'"ioT'"i1~v— "fl fl""i"iTn*iiap^T'9 tii i ViT "i r* 1 (5)Vi ottip^ 9 n p^1~ ^ / rrin 1~ a r'l" 

^^^-/IILhCT.^ L- K'-' Lk.^J LL-V— V.O ^XILL.LLOCX ^ ^ H-i^y J L V_. _L v^ll^LLLC^ .IICL-^ / ^k.^llL'W.^L''^ 




^n ol" P3 ■vm 1 • ~\ ann — "f^n" "■iTlon 'I" Tl n al" 1 1 t"Vi P^aap^ 1 ^ /no"l~pa"^ 

^ll^U-C .A.1LLX . XCLliy~ Cll ^±J\JLL U- X/ X O L- U.X Jk_/ IrXCCLOC . ^/ ll^L-C^ 




^n ol" P3 vm n • ~\ ano — ii-p-v^ii ■^'M'fa r\ a yz^ no'Pi "7 Tia a a ' "i T iroi la nl an l"^ /no"l~P3"^i 

^11^ L- C .^ILLX . X CLliy — XX C ^^C X CLliy C ^ Li/CL O / O XX V <J Li- O Li/ X O- X L- / ll^L-C^ 




^f" n TTipa al" amn '-»9nm — Ofl — 97*^11 •4Q«9Q7^/"l~nTTiP3a"l~ amn 
^ L. XILLCO UCLlLLU ^^UUJ UO ^ / ± X X , '± ^ .^I7£j<./ 1 LI LLC O UCLlLLLf ^ 




^ /"hnnn pi ^ 

^ / L. X C 




<tuple id="jklhgf 9788934774 .78" > 




<status> 




<basic>open</basic> 




</status> 




<rpid: class >assistant</rpid : class > 




<rpid : relationshipxrpid : assistant/ ></rpid : relationship> 




<contact priority="l . 0" >tel : +1-212- 555 -2222</contact> 




<note xml : lang="en" >She ' s my secretary</note> 




<timestamp>2 003-08-27Tll : 49 : 29Z</timestamp> 




</tuple> 




<dm:person> 




<rpid: class >presentity</rpid : class > 




<c : homepage >http : //example . com/~user2 </c : homepage > 




<c : card>http : //example . com/ ~user2/ card . vcd< /c : card> 




<rpid : act ivi ties xrpid : meeting/ ></rpid : activities> 




<rpid: place -type until = "2003-08-27T17 : 30 : OOZ" xrpid : of f ice/ ></rpid : place 


-type> 


</dm:person> 




</presence> 





P-Charging- Vector: The PS populates the icid parameter with a globally unique value and populates the 

identifier of its own network to the originating Inter Operator Identifier (101) parameter of 
this header. 
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Content-Type: Set to the value of the Accept header received in the SUBSCRIBE request or 

"application/pidf+xml" . 

The message body in the NOTIFY request that carries the presentity's presence state is formed as indicated in 
RFC 3863 [21], RFC 4479 [44], RFC 4480 [26], RFC 4482 [32] and draft-ietf-simple-prescaps-ext [25]. 

14. NOTIFY request (S-CSCF to RLS) - see example in table A.3.4.1-14 

The S-CSCF#1 forwards the NOTIFY request to the RLS. 



Table A.3.4.1-14: NOTIFY request (S-CSCF to RLS) 



NOTIFY sip: rls.homel.net SIP/2.0 






Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bKehuehjgt , 


SIP/2 . 


0/UDP 


ps . home2 . net ;branch=z9hG4bK348923 . 1 






Max-Forwards: 69 






P-Charging-Vector : 






P-Charging-Function-Addresses : ccf = [5555 : :b99 :c88 :d77 :e66] 


; ccf = 


[5555 : :a55 :b44 :c33 :d22] ; 


ecf=[5555: :lff:2ee: 3dd: 4ee] ; ecf = [5555 : : 6aa: 7bb: Sec: 


9dd] 




Record-Route : <sip:scscfl .homel .net ,- lr> 






From: 






To: 






Call-ID: 






CSeq: 






Subscription-State : 






Event : 






Contact : 






Content -Type : 






Content - Length : 
(...) 







P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

and populates the identifier of its own network to the originating Inter 
Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF populates the P-Charging-Function-Addresses header field to be 

passed to the RLS. 

15. 200 (OK) response (RLS to S-CSCF) - see example in table A.3.4.1-15 

The RLS generates a 200 (OK) response to the NOTIFY request. 



Table A.3.4.1-15: 200 (OK) response (RLS to S-CSCF) 



SIP/2.0 200 OK 




Via: 




P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423 551024 " 


orig- 


ioi=homel .net : term-ioi=homel .net 




From: 




To: 




Call-ID: 




CSeq: 




Content -Length: 





P-Charging- Vector: The RLS stores the originating Inter Operator Identifier (lOI) parameter and populates the 
identifier of its own network to the terminating Inter Operator Identifier (lOI) parameter of 
this header. 

16. 200 (OK) response (S-CSCF to PS) - see example in table A.3.4.1-16 

The S-CSCF#1 forwards the 200 (OK) response to the PS. 

Table A.3.4.1-16: 200 (OK) response (S-CSCF to PS) 
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SIP/2.0 200 OK 
P-Charging-Vector : 

Via: SIP/2. 0/UDP ps .home2 .net;branch=z9hG4bK348923 . 1 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter and populates 
the identifier of its own network to the terminating Inter Operator Identifier (lOI) parameter 
of this header. 

A.3.5 Network based watcher subscribing on behalf of IIVIS 
watcher to IIVIS presentities 



Home Network#1 



Home Network#2 



Network 
watcher 



HSS 



1 . Sh: User location 
query 



-2. SUBSCRIBE ► 

3. Evaluation of 
initial filte criteria 



-13. 20(1 (OK) 



-15. NOTIFY 



-16. 20) (OK) 



S-CSCF#1 



l-CSCF 



-4. SUBSCRIBE- 



-12. 200 (OK) - 



HSS 



5. Cx: User iocation^ 
query , 



-6. SUB! CRIBE 



-11. 2011 (OK) 



-14. NOTIF' 



-17. 200 (01 C) 



S-CSCF#2 AS(PS) 



7. Evaluation of 
initial filter criteria 



-8. SUBSCRIBE> 



9. Watcher 
authorisation 



-10.200 (OK)- 



Figure A.3.5-1 : Network based watcher subscribing on behalf of IMS watcher 
for presence information of IMS presentities 

Figure A.3.5-1 shows a trusted network based watcher subscribing on behalf of an IMS watcher to presence event 
notification about an IMS based presentity. The presentity is in a different IM CN subsystem than the network based 
watcher and the signalUng flow assumes that the IMS watcher on whose behalf the network based watcher subscribes is 
registered to the IMS network. The details of the signalUng flows are as follows: 

1. Sh: User Location Query procedure 
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The network based watcher sends a query to the HSS to find out the S-CSCF of the user on whose behalf the 
subscription is initiated. The HSS responds with the address of the current S-CSCF for the originating 
subscriber. 

2. SUBSCRIBE request (Network based watcher to S-CSCF) - see example in table A.3.5-2 

The SUBSCRIBE request is constructed and forwarded to S-CSCF. The S-CSCF is inserted into the Route 
header of the SUBSCRIBE request. 

Table A.3.5-2: SUBSCRIBE request (network watcher to S-CSCF) 



SUBSCRIBE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP watcher .homel .net;branch=z9hG4bK240f 34 . 1 

P- Access -Network- Info : 
Max-Forwards: 69 

P- Asserted- Identity : <sip : userl_publicl@homel . net> 
Privacy: none 

Route : <sip:scscfl. homel . net ; Ir ; orig> 

From : <sip : userl_publicl@homel . net> ; tag=31415 

To : <sip : user2_publicl@home2 . net> 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 61 SUBSCRIBE 

Event : PRESENCE 

Expires: 7200 

Accept : applicat ion/pidf +xml ; q=0 . 3 , applicat ion/pidf -dif f +xml ;q=l 
Contact: <sip: [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 
Content - Length : 



Request-URI: Public user identity of the user to whose events the subscriber subscribes to. 

P-Asserted-Identity: The network based watcher inserts the public user identity of the watcher on whose behalf 
the subscription is made into the P-Asserted-Identity header field. 

Route: The Route header is populated with the address of the S-CSCF obtained from the response 

to the user location query performed by the network based watcher on the Sh interface. 

Event: This field is populated with the value "presence" to specify the use of the presence package. 

Contact: The contact information of the network based watcher. 

3 . Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of the subscriber identified in the P-Asserted-Identity header field and 
evaluates the initial filter criteria. In this example, no AS is assumed to be involved. 

4. SUBSCRIBE request (S-CSCF to I-CSCF) - see example in table A.3.5-4 

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the 
destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, S-CSCF#1 forwards the SUBSCRIBE request directly to the I-CSCF in the destination 
network. 
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Table A.3.5-4: SUBSCRIBE (S-CSCF to l-CSCF) 



SUBSCRIBE sip :user2_publicl(Shome2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 

network . homel .net ;branch=z9hG4bK240f 34 . 1 , 
Max-Forwards: 68 

P-Asserted- Identity : <sip : userl_publicl@homel . net> 

Privacy : 

Record-Route : <sip : scscf 1 .homel .net; lr> 

From : 
To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



5. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [10]. 

Table A.3.5-5a provides the parameters in the SIP SUBSCRIBE request (flow 4), which are sent to the HSS. 



Table A.3.5-5a: Cx: User registration location procedure (l-CSCF to HSS) 



Message source 
and destination 


Cx: Information 
element name 


Information source in 
SIP SUBSCRIBE 


Description 


l-CSCF to HSS 


User Public Identity 


Request-URI 


This information element indicates 
the public user identity 



Table A.3.5-5b provides the parameters sent from the HSS that need to be mapped to the SIP SUBSCRIBE 
request (flow 6) and sent to the S-CSCF. 



Table A.3.5-5b: Cx: User location query procedure (HSS to l-CSCF) 



lUlessage source 
and destination 


Cx: Information 
element name 


lUlapping to SIP header 
in SIP SUBSCRIBE 


Description 


HSS to l-CSCF 


S-CSCF name 


Route header field 


This information indicates the serving 
CSCF's name of that user 



6. SUBSCRIBE request (l-CSCF to S-CSCF) - see example in table A.3.5-6 

The l-CSCF forwards the SUBSCRIBE request to the S-CSCF (S-CSCF#2) that will handle the termination. 
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Table A.3.5-6: SUBSCRIBE request (l-CSCF to S-CSCF) 



SUBSCRIBE sip:user2_publicl®home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
scscf 1 .homel .net;branch=z9hG4bK3 51g4 5. 1, SIP/2 .0/UDP 
network . homel . net ;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 67 

P- Asserted- Identity : 

Privacy : 

Route : <sip : scscf 2 . home2 . net ; lr> 
Record-Route : 
From : 
To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path for the subsequent requests. 

7. Evaluation of initial filter criteria 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criteria. For 
sip:user2_publicl @ho me2.net S-CSCF#2 has termination initial filter criteria with Service Point Trigger of 
Method = SUBSCRIBE and Event = "presence" that informs the S-CSCF to route the SUBSCRIBE request 
to the AS ps.home2.net. The S-CSCF#2 has preconfigured information not to create a Record-Route header 
for this request. 

8. SUBSCRIBE request (S-CSCF to PS) - see example in table A.3.5-8 

The S-CSCF forwards the SUBSCRIBE request to the PS. 

Table A.3.5-8: SUBSCRIBE request (S-CSCF to PS) 

SUBSCRIBE sip:user2_publicl(ahome2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP 

icscf 2_s .home2 . net ;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 

scscf 1 .homel .net, -branch=z9hG4bK351g45. 1, SIP/2 .0/UDP 

network . homel . net ;branch=z9hG4bK240f 34 . 1 
Max-Forwards: 66 
P- Asserted- Identity : 
Privacy : 

Route: <sip :ps . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> 
Record-Route: <sip: scscf 1 . homel . net ; lr> 

From : 
To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



9. Authorization of watcher 

The PS performs the necessary authorization checks on the watcher whose behalf the subscription is being 
made to ensure it is allowed to watch the presentity. In this example all privacy conditions are met, so the PS 
sends a 200 (OK) response to the S-CSCF. 

In the case where the privacy/authorization checks fails, then a necessary 2xx or 4xx response will be sent to 
the S-CSCF. The selection of the correct response code depends on the presentity's authorization policy 
document. 

10. 200 (OK) response (PS to S-CSCF) - see example in table A.3.5-10 
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The PS sends the response to S-CSCF#2. 

Table A.3.5-10: 200 (OK) response (PS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf2_s .home2 .net;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bK351g45 . 1 , SIP/2 . 0/UDP 

network. homel .net ;branch=z9hG4bK24 0f 34 . 1 
Record-Route : 
From: 

To: <sip:user2_publicl@home2 . net> ; tag=151170 

Call-ID: 

CSeq: 

Expires : 

Contact: <sip :ps . home2 . net> 
Content - Length : 



11. 200 (OK) response (S-CSCF to I-CSCF) - see example in table A.3.5-11 

S-CSCF#2 forwards the response to I-CSCF#2. 

Table A.3.5-1 1 : 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK351g45 . 1 , SIP/2 . 0/UDP 
network. homel .net ;branch=z9hG4bK24 0f 34 . 1 

Record-Route : 

From: 

To: 

Call-ID: 
CSeq: 
Expires : 
Contact : 
Content - Length : 



12. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.3.5-12 
I-CSCF#2 forwards the response to S-CSCF#1. 

Table A.3.5-12: 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 

network. homel . net ;branch=z9hG4bK24 0f 34 . 1 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Expires : 
Contact : 
Content - Length : 



13. 200 (OK) response (S-CSCF to network watcher) - see example in table A.3.5-13 

S-CSCF#1 forwards the response to request originator. 
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Table A.3.5-13: 200 (OK) response (S-CSCF to network watcher) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP network . homel . net ; branch=z9hG4bK240f 34 . 1 
Record-Route : 
From : 
To: 

Call-ID: 
CSeq: 
Expires : 
Contact : 
Content - Length : 
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14. NOTIFY request (PS to S-CSCF) - see example in table A.3.5-14 

As soon as the PS sends a 200 (OK) response to accept the subscription, it sends a NOTIFY request with the 
current state of the presentity's presence information that the watcher has subscribed and been authorized to. 
The NOTIFY request is sent to S-CSCF#1 . Based on the Accept header field of the SUBSCRIBE request, the 
PS decides to use partial notifications to provide further changes of presence information. The first 
notification always contains the full state. The 'application/pidf-diff H-xml' content type is used. 

Table A.3.5-14: NOTIFY request (PS to S-CSCF) 



NOTIFY sip: network . homel . net ; branch=z 9hG4bK24 Of 34 . 1 SIP/2.0 
Via: SIP/2. 0/UDP ps . home2 . net ; branch=z9hG4bK348923 . 1 
Max-Forwards: 70 

Route : <sip:scscfl. homel . net ; lr> 

From : <sip : user2_publicl@home2 . net> ; tag=151170 

To : <sip : userl_publicl@homel . net> ; tag=31415 

Call -ID: b89rjhnedlrf jflslj4 0a222 

CSeq: 42 NOTIFY 

Subscription-State: active; expires=7200 
Event : presence 
Contact: <sip : ps . home2 . net > 
Content-Type: application/pidf-diff +xml 
Content -Length: (...) 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

< dif f :pidf -full xmlns= "urn : ietf : params : xml : ns : pidf " 

xmlns : rpid="urn: ietf :params :xml :ns :pidf : rpid" 
xmlns : dif f= "urn : ietf : params : xml : ns : pidf : pidf -dif f " 
xmlns : dm= "urn : iet f : params : xml : ns : pidf : data -model " 
xmlns : pcp= "urn : iet f : params : xml : ns : pidf : caps " 
xmlns : c= "urn : iet f : params : xml : ns : pidf : cipid" 
ent ity= "pres : user2_publicl@home2 . net " version= " 1 " > 

< tuple id="a8 9 8a. 6 72 3 64 762364"> 
<status> 

<basic>open</basic> 

<rpid : pr ivacyx text />< /rpid : privacy> 

<rpid : status - icon>http : //example . com/ ~user2/ icon . gif < /rpid : status -icon> 
</ status> 

<rpid : c las s>sip</ rpid : class > 
<pcp : servcaps> 

<pcp : videof alse< /pep : video> 
<pcp : audio>true< /pep : audio 
</pcp : servcaps> 

< contact prior ity= " . 8 " >sip : user2_publicl(ahome2 . net< /contact > 
<note xml : lang= "en" >Don ' t Disturb Please ! </note> 
<note xml : lang= " f r " >Ne derangez pas, s'il vous plait</note> 
<timestamp>2003 -08-27T11 : 49 : 2 9Z</timestamp> 
</tuple> 

<tuple id="jklhgf 9788934774 .78" > 

<status> 

<basic>open</basic> 
</status> 

<rpid : class >assistant</ rpid : class > 

<rpid : relationshipxrpid : assistant/ ></rpid : relationship> 
<contact priority="l . 0">tel : +1 -2 12 -555 -2222</contact> 
<note xml : lang= "en" >She ' s my secretary</note> 
<timestamp>2 003-08-27Tll : 49 : 29Z</timestamp> 
</tuple> 

<dm:person> 

<rpid: class >presentity</ rpid: class > 
<c : homepage >http : //example . com/~user2</c :homepage> 
<c : card>http : //example . com/ ~user2 /card. vcd</c : card> 
<rpid: activities xrpid: meeting/ >< /rpid: activities > 

<rpid: place- type until = "2003-08-27T17 : 30 : OOZ" xrpid : of f ice/ ></rpid : place- type> 

< /dm : person> 

</diff :pidf-full> 



From: The tag of this field matches that of the To field in the received 200 (OK) response for the 

SUBSCRIBE request. 
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Content-Type: Set to the preferred value of the Accept header received in the SUBSCRIBE request. 

The message body in the NOTIFY request that carries the presence information of the presentity is formed as 
indicated in RFC 3863 [21], RFC 4480 [26], RFC 4482 [32], draft-ietf-simple-prescaps-ext[25], 
RFC 4479 [44] and draft-ietf-simple-partial-notify [24]. 

15. NOTIFY request (S-CSCF to network watcher) - see example in table A.3.5-15 

The S-CSCF#1 forwards the NOTIFY request to the network watcher 



Table A.3.5-15: NOTIFY request (S-CSCF to network watcher) 



NOTIFY sip: network. homel .net ;branch=z9hG4bK240f 34 . lSIP/2 





Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK351g45 . 1 , 


SIP/2 .0/UDP 


ps . home2 . net ;branch=z9hG4bK348923 . 1 




Max-Forwards: 69 




Privacy : 




Record-Route : <sip:scscfl .homel .net ; lr> 




From : 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Event : 




Contact : 




Content - Type : 




Content - Length : 
(...) 





16. 200 (OK) response (network watcher to S-CSCF) - see example in table A.3.5-16 

The network watcher forwards the 200 (OK) response to S-CSCF#1. 

Table A.3.5-16: 200 (OK) response (network watcher to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 

ps . home2 . net ;branch=z9hG4bK348923 . 1 
P- Access -Network- Info : 
From : 
To: 

Call-ID: 
CSeq: 

Content - Length : 



17. 200 (OK) response (S-CSCF to PS) - see example in table A.3.5-17 

S-CSCF#2 forwards the 200 (OK) response to the PS. 

Table A.3.5-17: 200 (OK) response (S-CSCF to PS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ps .home2 .net;branch=z9hG4bK348923 . 1 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 
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A.3.6 Watcher subscribing to state changes in XIVIL document, 
UE in visited network 

A.3.6. 1 Watcher subscribing to clianges made via XCAP in iiis resource list, 
UE in visited network - Successful subscription 



Visited Network 



Home Networl< of UE 



UE 



P-CSCF S-CSCF 



1. SUBSCRIBE 



2. SUBSCRIBE 



3. Evaluation of 
Initial filter 
criteria 



7. 200 (OK) 



8. 200 (OK) 



10. NOTIFY 



1 1 . NOTIFY 



12. 200 (OK) 



13. 200 (OK) 



4. SUBSCRIBE 



6. 200 (OK) 



9. NOTIFY 



14. 200 (OK) 



1 5. user retrieves current resource list via XCAP GET 



19. NOTIFY 



18. NOTIFY 



20. 200 (OK) 



21 . 200 (OK) 



17. NOTIFY 



22. 200 (OK) 



AS(RLS) 



5. Authorisation 



1 6. resource list gets 
modifed via XCAP 



Figure A.3.6.1-1 : Watcher subscribing to clianges made via XCAP in Iiis resource list 

Figure A.3.6.1-1 shows a watcher subscribing to notifications of state changes made via XCAP in his resource list. The 
details of the flows as follows: 
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1 . SUBSCRIBE request (UE to P-CSCF) - see example in table A.3.6.1-1 

A watcher agent in a UE wishes to get notification when his resource list gets modified via XCAP. In order 
to initiate a subscription to XCAP document changes in RLS, the UE generates a SUBSCRIBE request 
indicating support for "ua-profile", together with an indication of the length of time this periodic subscription 
should last. 

Table A.3.6.1-1 : SUBSCRIBE request (UE to P-CSCF) 



SUBSCRIBE sip :userl_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKehuefdam 
Max- Forwards : 70 

P-Access -Network- Info : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip :pcscf 1 . visitedl .net : 7531; Ir ; comp=sigcomp> , <sip : orig@scscf 1 .homel .net; lr> 

P- Prefer red- Identity : <sip : userl_publicl@homel . net> 

Privacy: none 

From: <sip : userl_publicl@homel .net>; tag=31415 

To: <sip :userl_publicl@homel .net> 

Call -ID: b89rjhnedlrf jflslj4 0a222 

CSeq: 123 SUBSCRIBE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l- 96 ; spi-c=98765432 ; spi -s =8765432 1 ; port- 
c=8642; port-s=7531 

Event : ua-prof ile; prof ile-type=appl icat ion; app-id=resource- lists ; document ="users/userl" 

Expires: 7200 

Accept : application/xcap-dif f +xml 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 
Content -Length: 



Request-URI: The users own SIP URI to get notifications of changes on all lists owned by the user. 

Event: This field is populated with the value "ua-profile" to specify the use of the ua-profile package to 

get notified of changes to XCAP documents. The "app-id" in the field identifies the XCAP 
application usage. The "document" further details the document that is being subscribed. 

Accept: This field is populated with the value "application/xcap-diff+xml" indicating that the UE supports 

the MIME type. 



To: 



Same as the Request-URI. 
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2. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table A.3.6.1-2 

The P-CSCF looks up the serving network information for the pubHc user identity that was stored during the 
registration procedure. The SUBSCRIBE request is forwarded to S-CSCF#1. A Route header is inserted into 
SUBSCRIBE request. The information for the Route header is taken from the service route determined 
during registration. 

Table A.3.6.1-2: SUBSCRIBE request (P-CSCF to S-CSCF) 



StJBSCRIBE sip :userl_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK120f 34 . 1 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
P-Access -Network- Info : 

Route : <sip : orig@scscf 1 .homel .net ; lr> 
Max- Forwards : 69 

P- Asserted- Identity: < sip : user l_publicl@homel .net> 

P -Charging -Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=223 551024" 
Privacy : 

Record-Route : < sip : pcscf 1 .visitedl .net; lr> 

Route : <sip : scscf 1 .homel .net; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Supported : 
Expires : 
Accept : 
Contact : 
Content - Length : 



3 . Evaluation of initial filter criteria 

The S-CSCF vaUdates the service profile of this subscriber and evaluates the initial filter criteria. For 
sip:userl_pubIicl@homel.net the S-CSCF has originating initial Filter Criteria with Service Point Trigger of 
Method = SUBSCRIBE AND Event = "ua-profile" that informs the S-CSCF to route the SUBSCRIBE 
request to the AS sip:rls.homel.net. 

4. SUBSCRIBE request (S-CSCF to RLS) - see example in table A.3.6.1-4 

The S-CSCF forwards the SUBSCRIBE request to the RLS. 

Table A.3.6.1-4 SUBSCRIBE request (S-CSCF to RLS) 



SUBSCRIBE sip:userl_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK344a65 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net ;branch=z9hG4bK12 Of 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKehuef dam 
Max-Forwards: 68 
P -Access -Network- Info : 

P- Asserted- Identity : <sip : userl_publicl(ahomel .net>, <tel:+l-212-555-llll> 

P- Charging -Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=2 2 3 551024 " ; orig-ioi=homel .net 
P- Charging- Function-Addresses : ccf = [5555: :b99:c88:d7 7:e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy : 

Record-Route : <sip : origOscscf 1 .homel .net ; lr>, <sip : pcscf 1 .visitedl .net; lr> 
Route: <sip : rls . homel . net ; lr> , <sip : origOscscfl . homel . net ; lr> 
From : 
To: 

Call-ID: 
CSeq: 
Event : 
Supported : 
Expires : 
Accept : 
Contact : 
Content - Length : 



P-Charging- Vector: The S-CSCF populates the identifier of its own network to the originating 

Inter Operator Identifier (lOI) parameter of this header. 
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P-Charging-Function-Addresses: The S-CSCF populates the P-Charging-Functioii-Addresses header field to be 

passed to the RLS. 

5. Authorization 

The RLS performs the necessary authorization checks on the originator to ensure that he/she is authorized to 
subscribe to XML document changes. In this example this condition has been met, so the RLS sends a 200 
(OK) response to the S-CSCF. 

6. 200 (OK) response (RLS to S-CSCF) - see example in table A.3.6.1-6 

The RLS sends the response to the S-CSCF. 

Table A.3.6.1-6: 200 (OK) response (RLS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK344a65 . 1 , SIP/2. 0/UDP 
pcscf 1 . visitedl .net ;branch=z9hG4bK12 0f 34 .1, SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" ; orig-ioi=homel .net; 
term-ioi=homel .net 

Record-Route : 

From: 

To : <sip :userl_publicl@homel . net> ; tag=151170 

Call-ID: 

CSeq: 

Expires : 

Contact : 

Content -Length: 



7. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.6.1-7 

The S-CSCF forwards the response to the P-CSCF. 

Table A.3.6.1-7: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK12 Of 34 . 1 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
P -Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223 551024 " 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Expires : 

Contact : 
Content-Length : 



8. 200 (OK) response (P-CSCF to UE) - see example in table A.3.6.1-8 

The P-CSCF forwards the response to the watcher agent in the UE. 



Table A.3.6.1-8: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] 


: 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 


Record-Route : <sip : origOscscf 1 .homel .net 


; lr>, < sip : pcscf 1 .visitedl .net : 7531 ; Ir ; comp=sigcomp> 


From: 




To: 




Call-ID: 




CSeq: 




Expires : 




Contact : 




Content - Length : 
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9. NOTIFY request (RLS to S-CSCF) - see example in table A.3.6.1-9 

The RLS generates a NOTIFY request including the xcap-diff document as a result of the SUBSCRIBE 
request. As this is the initial NOTIFY it contains only the new-etag, previous-etag and document- selector 
elements. 

Table A.3.6.1-9 NOTIFY request (RLS to S-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP rls .homel .net;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 70 

P- Charging -Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=3 2 3 551024" ; orig-ioi=homel .net 
P-Charging-Function-Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Route : <sip : scscf 1 .homel .net ; lr>, <sip :pcscf 1 . visitedl .net; lr> 
From: <sip : userl_@homel . net> ; tag=151170 
To : <sip :userl_publicl@homel .net>; tag=31415 
Call -ID: b89rjhnedlrf jflslj4 0a222 
CSeq: 89 NOTIFY 

Subscript ion- State : active ;expires=72 00 

Event : ua-prof ile 

Contact: <sip : rls . homel . net> 

Content -Type : application/xcap-dif f +xml ;charset="UTF-8" 
Content - Length : 

<?xml version="l . 0" encoding="UTF-8 " ?> 

<xcap-dif f xmlns="urn: ietf :params :xml :ns :xcap-dif f " 

xcap-root="http : //xcap .homel .net /services" > 

<document doc -selector=" resource -lists/users/userl/ friends" 

new- etag= " 7hahsd " / > 
</ document > 

<document doc -selector=" resource- lists/users/userl/coworkers" 

new-etag="f f ds66a" > 
</ document > 

</xcap-dif f > 



The content of the document element contains a new-etag and a previous etag element with identical value 
and no list of instructions. This way it is indicated that this is the reference XML diff document. This 
documents has only the information about the etags and the document URI"s covered by that subscription. 

10. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.3.6.1-10 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 

Table A.3.6.1-10: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

rls .homel . net ;branch=z9hG4bK240f 34 . 1 
Max-Forwards: 69 

P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323 551024 " 

P-Charging-Function-Addresses : 

Route : <sip :pcscf 1 .visitedl .net ; lr> 

Record-Route : <sip : scscf 1 .homel .net; lr> 

From: 

To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content - Length : 

(...) 
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1 1 . NOTIFY request (P-CSCF to UE) - see example in table A.3.6.1-11 

The P-CSCF forwards the NOTIFY request to the watcher in the UE. 



Table A.3.6.1-11 : NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ;comp=sigcomp 


SIP/2 . 


Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 


scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


0/UDP 


rls . homel .net ;branch=z9hG4bK24 0f 34 . 1 




Max - Forwards : 68 




Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl. 


visitedl .net : 7531; Ir ; comp=sigcomp> 


From : 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Event : 




Contact : 




Content - Length : 




(...) 





12. 200 (OK) response (UE to P-CSCF) - see example in table A.3.6.1-12 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.3.6.1-12: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscfl .visitedl . net ;branch=240f 34 . 1 , 


SIP/2 . 0/UDP 


scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 


0/UDP 


rls .homel .net ;branch=z9hG4bK24 0f 34 . 1 




P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content -Length: 





13. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.3.6.1-13 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.3.6.1-13: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

rls .homel .net ;branch=z9hG4bK24 0f 34 . 1 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323 551024" 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



14. 200 (OK) response (S-CSCF to RLS) - see example in table A.3.6.1-14 

The S-CSCF#2 forwards the response to the RLS in the home network of the UE. 
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Table A.3.6.1-14: 200 (OK) response (S-CSCF to RLS) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP rls . homel . net ; branch=z9hG4bK240f 34 . 1 




P- Access -Network- Info : 




P-Charging-Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=323551024 " 


orig-ioi=homel . net ; 


term-ioi=homel .net 




From : 




To: 




Call-ID: 




CSeq: 




Content - Length : 





15. User retrieves current resource list via XCAP get 

As userl does not have a local copy of the resource list identified by the etag he retrieves the corresponding 
list via XCAP get. 

16. Resource List gets modified via XCAP 

The resource list of userl gets modified via XCAP procedures. 

17. NOTIFY request (RLS to S-CSCF) - see example in table A.3.6.1-17 

In this example it is assumed that the RLS has received a XCAP request to delete user2_public@homel.net 
from the resource Ust of userl. 

Table A.3.6.1-17 NOTIFY request (RLS to S-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP rls .homel .net;branch=z9hG4bK240f 34 . 1 
Max-Forwards: 70 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423 551024" ; orig-ioi=homel .net 
P-Charging-Function-Addresses : ccf = [5555 : :b99 :c88 :d77 :e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Route : <sip: scscf 1 .homel .net ; lr>, <sip :pcscf 1 . visitedl .net; lr> 
From: <sip : userl_publicl@homel . net> ; tag=151170 
To : <sip :userl_publicl .homel .net>; tag=31415 
Call -ID: b89rjhnedlrf jflslj4 0a222 
CSeq: 90 NOTIFY 

Subscript ion- State : active; expires=5000 

Event : ua-prof ile 

Contact: <sip : rls . homel . net> 

Content -Type : application/xcap-dif f +xml ;charset="UTF-8" 
Content -Length: (...) 



<?xml version="l . 0" encoding="UTF-8 " ?> 

<xcap-dif f xmlns="urn: ietf :params :xml :ns :xcap-dif f " 
xcap-root="http : //xcap .homel .net /services" > 



<document doc -selector=" resource- lists/users/userl/coworkers" 
new- etag= " aaaab " previous - etag= " f f ds6 6a " > 
<change-log> 

<put-eventnode-selector="resource-lists/list [@name="coworkers" ] " content- 
type="application/el+xml"> 

<! [CDATA [<entry uri=" sip : new-worker@example . com" />] ] > 
< /put- event > 
< /change -log> 
</ document > 
</xcap-dif f > 



Content-Type: Set to appUcation/xcap-diff+xml. 

The message body in the NOTIFY request contains information of the new-etag of the changed document, 
the change method and the element that was changed in accordance with draft-ietf-simple-xcap-diff [39]. 

18. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.3.6.1-18 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 
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Table A.3.6.1-18: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip : [5555 :: aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

rls . homel . net ;branch=z9hG4bK240f 34 . 1 
Max-Forwards: 69 

P-Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423 551024" 

P-Charging-Function-Addresses : 

Route : <sip : pcscf 1 . visitedl . net ; lr> 

Record-Route : <sip:scscfl .homel .net ,- lr> 

From: 

To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content Type : 
Content - Length : 

(...) 



19. NOTIFY request (P-CSCF to UE) - see example in table A.3.6.1-19 

The P-CSCF forwards the NOTIFY request to the watcher in the UE. 



Table A.3.6.1-19: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp 


SIP/2 . 


Via: SIP/2. 0/UDP pcscf 1 .visitedl .net ;branch=240f 34 . 1 , 


SIP/2 . 0/UDP 


scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


0/UDP 


rls . homel . net ;branch=z9hG4bK240f 34 . 1 




Max-Forwards: 68 




Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl. 


visitedl .net : 7531; Ir ; comp=sigcomp> 


From : 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Require : 




Content -Type : 




Content - Length : 




(...) 





20. 200 (OK) response (UE to P-CSCF) - see example in table A.3.6.1-20 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.3.6.1-20: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf 1 .visitedl . net ;branch=24 Of 34 . 1 , 


SIP/2 . 0/UDP 


scscf 1 .homel .net ;branch=z9hG4bK332b23 .1, SIP/2 . 


0/UDP 


rls .homel .net ;branch=z9hG4bK24 0f 34 . 1 




P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content -Length: 





21. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.3.6.1-21 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 
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Table A.3.6.1-21 : 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

rls . homel . net ;branch=z9hG4bK240f 34 . 1 
P- Access -Network- Info : 

P -Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423 551024" 

From : 

To: 

Call-ID: 
CSeq: 

Content - Length : 



22. 200 (OK) response (S-CSCF to RLS) - see example in table A.3.6.1-22 

The S-CSCF#2 forwards the response to the RLS in the home network of the UE. 

Table A.3.6.1-22: 200 (OK) response (S-CSCF to RLS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP rls . homel . net ;branch=z9hG4bK240f 34 . 1 
P-Access-Network-Inf o : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423551024" ; orig-ioi=homel .net,• 
term-ioi=homel .net 

From: 
To: 

Call-ID: 

CSeq: 

Content - Length : 
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A.4 Signalling flows demonstrating how presentities 
update presence information 

A.4.1 Introduction 

This subclause covers the signalUng flows that show how presentities update presence information in the PS. 

A.4.2 Initial publication or modification of presence information by 
UE 

A.4.2. 1 Successful publication 

Home Network#1 



UE 



P-CSCF#1 





S-CSCF#1 




PS 



1. PUBLISH 



2. PUBLISH 



3. Evaluation of 
initial 
filter criteria 



4. PUBLISH 



5. Publisher 
authorisation 



-8. 200 (OK)- 



7. 200 (OK) 



-6. 200 (OK)- 



Figure A.4.2.1-1: UE publishing presence information 

The UE may pubUsh the partial presence information or the full presence information about a presentity to the PS. 
In this example, it is assumed that the UE publishes the fuU presence information. 
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Figure A.4.2. 1-1 shows a UE publishing or modifying already existing presence information about a presentity. The 
details of the signalling flows as follows: 

1 . PUBLISH request (UE to P-CSCF) - see example in table A.4.2.1-1 

A PUA in a UE wishes to pubhsh presence information. To initiate the pubhcation, the UE generates a 
PUBLISH request according to RFC 3903 [23] containing the presence information that it wishes to publish. 

Table A.4.2.1-1: PUBLISH request (UE to P-CSCF) 



PUBLISH sip :userl_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 70 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip :pcscf 1 . visitedl .net : 7531;lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net; lr> 

P- Preferred- Identity : <sip : userl_publicl@homel . net> 

Privacy : none 

From: <sip : userl_publicl@homel . net> ; tag=31415 

To: <sip:userl_publicl@homel .net> 

Call -ID: b89rjhnedlrf jflslj4 0a222 

CSeq: SI PUBLISH 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 
Event : presence 
Expires: 72 00 

Content-Type : application/pidf +xml 
Content -Length: (...) 

<?xml version="l . 0" encoding="UTF-8 " ?> 

<presence xmlns="urn : ietf :params :xml : ns :pidf " 

xmlns : rpid="urn : ietf :params : xml : ns :pidf : rpid" 
xmlns : dm="urn : ietf :params : xml : ns :pidf : data-model " 
xmlns :pcp="urn: ietf :params :xml :ns :pidf : caps" 
xmlns : c= "urn : ietf :params : xml : ns :pidf : cipid" 
entity= "pres : user2_publicl@home2 . net " > 

<tuple id= "a8 098a. 6723 647623 64 "> 
<status> 

<basic>open</basic> 

</status> 

<rpid: class>sip</rpid: class > 

<rpid : pr ivacyx text />< /rpid : privacy> 

<rpid : status - icon>http : / /example . com/ -user 2 / icon . gif </rpid : status -icon> 

<pcp : servcaps> 

<pcp : video false< /pep : video 
<pcp : audiotrue< /pep : audio> 

</pcp : servcaps> 

< cent act priority^ " . 8 " >sip : user2_publicl(ahome2 . net< /contact > 
<note xml : lang= "en" >Don ' t Disturb Please ! </note> 
<note xml : lang= " f r " >Ne derangez pas, s'il vous plait</note> 
<timestamp>2003-08-27Tll :49 : 2 9Z</timestamp> 
</tuple> 

<tuple id="jklhgf 9788934774 .78" > 

<status> 

<basic>open</basic> 
</status> 

<rpid: class>assistant</rpid: class> 

<rpid : relat ionshipxrpid : assistant />< /rpid : relationship> 
<contact priority="l . 0">tel : +1 -2 12 -555 -2222</contact> 
<note xml : lang= "en" >She ' s my secretary</note> 
<timestamp>2 003-08-27Tll : 49 : 29Z</timestamp> 
</tuple> 

<dm : person> 

<rpid: class>presentity</rpid: class> 

<c : homepage >http : / / example . com/~user2</c : homepage > 

<c : card>http : //example . com/ -user 2 /card . vcd</c : card> 

<rpid: place -type until="2003-08-27T17 : 30 : OOZ " xrpid : of f ice/ ></rpid : place- type> 
</dm:person> 

</presence> 
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Request-URI: Public user identity whose presence information the PUA intends to pubUsh. 

Event: This field is populated with the value "presence" to specify the use of the presence package. 

To: Same as the Request-URI. 

Content-Type: Set to the value "appUcation/pidf+xml". 

The message body in the PUBLISH request that carries the presence update state is formed as indicated in 
RFC 3863 [21], RFC 4480 [26], draft-ietf-simple-prescaps-ext [25], RFC 4482 [32] draft-ietf-simple-partial- 
notify [24] and RFC 4479 [44]. 

2. PUBLISH request (P-CSCF to S-CSCF) - see example in table A.4.2.1-2 

P-CSCF looks up the serving network information for the public user identity that was stored during the 
registration procedure. The PUBLISH request is forwarded to the S-CSCF. A Route header is inserted into 
PUBLISH request. The information for the Route header is taken from the service route determined during 
registration. 

Table A.4.2.1-2: PUBLISH request (P-CSCF to S-CSCF) 



PUBLISH sip :userl_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .homel .net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
P-Access-Network-Inf o : 
Max- Forwards : 69 

P-Asserted- Identity : <sip : userl_publicl@homel .net> 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 
Privacy : 

Route : <sip : origOscscf 1 .homel .net; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Content-Type : 
Content - Length : 

(...) 



3 . Evaluation of initial filter criteria 

S-CSCF vaUdates the service profile of the publisher and evaluates the initial filter criteria. For 
userl_publicl@homel.net S-CSCF#1 has originating initial Filter Criteria with Service Point Trigger of 
Method = PUBLISH AND Event = "presence" AND Request-URI = "sip:userl_publicl@homel.net" that 
informs the S-CSCF to route the PUBLISH request to the PS ps.homel.net. 
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4. PUBLISH (S-CSCF to PS) - see example in table A.4.2.1-4 
The S-CSCF#1 forwards the PUBLISH request to the PS. 

Table A.4.2.1-4: PUBLISH request (S-CSCF to PS) 



PUBLISH sip :userl_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
P -Access -Network- Info : 
Max-Forwards: 68 
P- Asserted- Identity : 

P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024 " ; orig- ioi=homel .net 
P-Charging- Function-Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : :a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : Sec : 9dd] 
Privacy : 

Route: <sip :ps . homel . net ; lr> , <sip : scscfl . homel . net ; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Content -Type : 
Content - Length : 

(...) 



P-Charging- Vector: The S-CSCF populates the icid parameter with a globally unique value and 

populates the identifier of its own network to the originating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF populates the P-Charging-Function-Addresses header field to be 

passed to the PS. 

5 . Authorization of publisher 

The PS performs the necessary authorization checks on the originator to ensure it is allowed to pubUsh the 
presentity's presence information. In this example all privacy conditions are met, so the PS sends a 200 (OK) 
response to the S-CSCF. 

6. 200 (OK) response (PS to S-CSCF) - see example in table A.4.2.1-6 

The PS sends the response to S-CSCF. 



Table A.4.2.1-6: 200 (OK) response (PS to S-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP scscfl .homel .net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 




pcscf 1 .homel .net ;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 




P-Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" ; 


orig- 


ioi=homel . net : term- ioi=homel . net 




P-Charging -Function- Addresses : ccf=[5555::b99:c88:d7 7:eGG]; ccf=[5555: 


:a55 :b44 :c33 :d22] ; 


ecf = [5555: :lff:2ee: 3dd: 4ee] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 




From: 




To : < sip : user l_publicl®homel .net> ; tag=15117 




Call-ID: 




CSeq: 




Expires: 7200 




SIP-ETag: 123xy 




Content -Length: 





P-Charging- Vector: The PS stores the originating Inter Operator Identifier (lOI) parameter and 

populates the identifier of its own network to the terminating Inter Operator 
Identifier (lOI) parameter of this header. 
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P-Charging-Function-Addresses: The PS stores the P-Charging-Function-Addresses header field and passes 

this header to the S-CSCF. 

SIP-ETag: This field is populated with a locally unique entity-tag to associate further 

pubUcations of this event state. 

7. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.2.1-7 

S-CSCF forwards the response to P-CSCF. 



Table A.4.2.1-7: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscfl.homel 


net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 


[5555: : aaa : bbb : ccc : ddd] 


: 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 


P-Charging-Vector : icid-value 


="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 


P-Charging-Function-Addresses 




From : 




To: 




Call-ID: 




CSeq: 




Expires : 




SIP-ETag: 




Content - Length : 





P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter 

and removes the orig-ioi and the term-ioi parameters. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the P-CSCF. 

8. 200 (OK) response (P-CSCF to UE) - see example in table A.4.2.1-6 

P-CSCF forwards the response to the PUA in the UE. 

Table A.4.2.1-8: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 
CSeq: 
Expires : 
SIP-ETag: 
Content - Length : 
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A.4.3 Refreshing of presence information by UE 

A.4.3.1 Successful refresh 

Home Network#1 



UE 



P-CSCF#1 



S-CSCF#1 



PS 



1. PUBLISH 



2. PUBLISH 



3. Evaluation of 
initial 
filter criteria 



7. 200 (OK) 



4. PUBLISH 



5. Publisher 
authorisation 



6. 200 (OK) 



8. 200 (OK) 



Figure A.4.3.1-1: UE updating presence information 

Figure A.4.3.1-1 shows an UE refreshing the presence information about a presentity. The details of the signalling flows 
are as follows: 

1 . PUBLISH request (UE to P-CSCF) - see example in table A.4.3.1-1 

A PUA in a UE wishes to refresh already existing presence information. To initiate the publication, the UE 
generates a PUBLISH request according to RFC 3903 [23]. 

Table A.4.3.1-1: PUBLISH request (UE to P-CSCF) 



PUBLISH sip:userl_publicl(ahomel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P-Access -Network- Info: 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip : pcscf 1 . visitedl . net : 753 1 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P- Preferred- Identity : <sip : userl_publicl(ahomel . net> 

Privacy: none 

From : <sip : userl_publicl(ahomel . net> ; tag=31415 

To : <sip : userl_publicl@homel . net > 

Call -ID: bSSrjhnedlrf jf lslj4 0alll 

CSeq: 61 PUBLISH 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 
Event : presence 
SIP-If -Match: 123xy 
Expires: 72 00 
Content - Length : 



Request-URI: Pubhc user identity whose presence information the PUA intends to publish. 

Event: This field is populated with the value "presence" to specify the use of the presence package. 
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To: Same as the Request-URI. 

SIP-If-Match: This field is populated with the entity-tag earlier provided by the PS in the SIP-ETag header field 
of the previous 200(OK) response and is used as a versioning precondition to the PUBLISH 
refresh. 

2. PUBLISH request (P-CSCF to S-CSCF) - see example in table A.4.3.1-2 

P-CSCF looks up the serving network information for the pubhc user identity that was stored during the 
registration procedure. The PUBLISH request is forwarded to the S-CSCF. A Route header is inserted into 
PUBLISH request. The information for the Route header is taken from the service route determined during 
registration. 

Table A.4.3.1-2: PUBLISH request (P-CSCF to S-CSCF) 



PUBLISH sip: userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 
[5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
P-Access-Network-Inf o : 
Max-Forwards: 69 

P-Asserted- Identity : < sip : user l_publicl@homel .net> 

P- Charging- Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=023 551024" 
Privacy : 

Route : <sip : origOscscf 1 . homel . net ; lr> 

From: 

To: 

Call-ID: 

CSeq: 
Event : 

SIP-If-Match: 
Expires : 
Content - Length : 



P-Charging- Vector: The P-CSCF populates the icid parameter with a globally unique value. 

3 . Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of this publisher and evaluates the initial filter criteria. For 
userl_pubhcl@homel.net the S-CSCF has originating initial Filter Criteria with Service Point Trigger of 
Method = PUBLISH AND Event = "presence" AND Request-URI = "sip:userl_publicl@homel.net" that 
informs the S-CSCF to route the PUBLISH request to the PS ps.homel.net. 

4. PUBLISH (S-CSCF to PS) - see example in table A.4.3.1-4 

The S-CSCF forwards the PUBLISH request to the PS. 

Table A.4.3.1-4: PUBLISH (S-CSCF to PS) 



PUBLISH sip:userl_publicl®homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG4bK351g45 . 1 , SIP/2 . O/tTDP 
pcscf 1 .homel .net, •branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

P -Access -Network- Info : 

Max-Forwards: G8 

P -Asserted- Identity: 

P- Charging -Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig-ioi=homel .net 
P-Charging-Function-Addresses : ccf = [5555 : :b99 :c88 :d77 :e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy : 

Route: <sip :ps . homel . net ; lr> , <sip : scscfl . homel . net ; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 

SIP-If-Match: 

Expires : 
Content-Length : 
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P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

and populates the identifier of its own network to the originating Inter 
Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF populates the P-Charging-Function- Addresses header field to be 

passed to the PS. 

5 . Authorization of publisher 

The PS performs the necessary authorization checks on the originator to ensure it is allowed to publish the 
presentity's presence information. In this example aU privacy conditions are met, so the PS sends a 200 (OK) 
response to the S-CSCF. 

6. 200 (OK) response (PS to S-CSCF) - see example in table A.4.3.1-6 

The PS sends the response to S-CSCF. 



Table A.4.3.1-6: 200 (OK) response (PS to S-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 




pcscf 1 .homel .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ;branch=z9hG4bKnashds7 




P-Charging-Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023555517" ; 


orig- 


ioi=homel . net ; term- ioi=homel . net 




P-Charging- Function-Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : 


:a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd:4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 




From: 




To : <sip :userl_publicl@homel . net> ; tag=151170 




Call-ID: 




CSeq: 




Expires: 72 00 




SIP-ETag: 345abc 




Content - Length : 





P-Charging- Vector: The PS stores the originating Inter Operator Identifier (lOI) parameter and 

populates the identifier of its own network to the terminating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The PS stores the P-Charging-Function- Addresses header field and passes 

this header to the S-CSCF. 

SIP-ETag: This field is populated with a new locally unique entity-tag. 

7. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.3.1-7 

S-CSCF#1 forwards the response to P-CSCF. 



Table A.4.3.1-7: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf 1. homel 


net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 .0/UDP 


[555 5 : : aaa : bbb : ccc : ddd] 


: 13 5 7 ; comp=sigcomp ;branch=z9hG4bKnashds7 


P-Charging-Vector : icid-value 


="AyretyU0dm+6O2IrT5tAFrbHLso=023 555517" 


P - Cha r ging - Func t i on - Addr e s s e s 




From : 




To: 




Call-ID: 




CSeq: 




Expires : 




SIP-ETag: 




Content - Length : 





P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter 

and removes the orig-ioi and the term-ioi parameters. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the P-CSCF. 
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8. 200 (OK) response (P-CSCF to UE) - see example in table A.4.3.1-6 

P-CSCF#1 forwards the response to the PUA in the UE. 

Table A.4.3.1-8: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 
Expires : 
SIP-ETag: 
Content - Length : 



A.5 PS notifying watcher of updates to presence 
information 

A.5.1 Introduction 

This subclause covers the signalUng flows that show how the PS notifies watchers of updates to presence information. 

A.5.2 Watcher and presentity in the different networks, UE in the 
home network 



A.5.2. 1 Successful notification 



Presentity Home Network 
_(Hqme2.rietX 



AS(PS) 



S-CSCF#2 



I-CSCF 



Watcher Home Network (Home1 .net) 



S-CSCF#1 



HSS 



P-CSCF 





1. NOTIFY 


► 


2. NOTIFY 






6. 200 (OK) 




^ 5. 200 (OK) 








< 







UE 



3. NOTIFY 



4. 200 (OK) 



Figure A.5.2.1-1 : Notification to watcher in the visited network 

Figure A.5.2.1-1 shows how a watcher is notified of updates to a presentity's presence information. The signalhng flow 
is apphcable to the case where the watcher and presentity are in the same or in different IM CN subsystems. 
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1 . NOTIFY request (PS to S-CSCF) - see example in table A.5.2.1-1 

The PS determines which authorized watchers are entitled to receive the updates of the presence information 
for this presentity. For each appropriate watcher, the PS sends a NOTIFY request that contains the updated 
state of presence information. The NOTIFY request may either contain the complete set of presence 
information, or only the information that has changed since the last notification. In this example, the watcher 
indicated preference for partial notification in the SUBSCRIBE request, so the NOTIFY request is 
formulated according to draft-ietf-simple-partial-notify [24] and draft-ietf-simple-partial-pidf-format [38] by 
including only the information that has changed since the last notification. (Note that the first NOTIFY 
request has contained the full state of the presence information.) 

Table A.5.2.1-1 : NOTIFY request (PS to S-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP ps .home2 .net;branch=z9hG4bK240f 34 . 1 
Max - Forwards : 7 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=523551024" ; orig-ioi=home2 .net 

Route: <sip : scscf 1 . homel . net ; lr> , <sip : pcscf 1 . homel . net ; lr> 

From: <sip : user2_publicl@home2 . net> ; tag=151170 

To : <sip : userl_publicl@homel . net > ; tag=3 1415 

Call -ID: b89rjhnedlrf jflslj4 0a222 

CSeq: 43 NOTIFY 

Subscript ion- State : active ;expires=5000 
Event : presence 
Contact: <sip : ps . home2 . net> 
Content-Type : application/pidf -dif f +xml 
Content -Length : (...) 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

<pidf -dif f xmlns= "urn : ietf : params : xml : ns : pidf -dif f "version=" 1" 
entity= "pres : user2 j>ublicl(ahome2 . net " > 

<add parent= "presence" sel="*[2]"> 
< ! [CDATA[ 

<tuple id="xfjsk"> 
<status> 

<basic>open</basic> 
</status> 

<rp : class >voice</rp : class > 

<rp : status- icon>http : //example . com/ -user 2 / iconABC . gif </rp : status- icon> 
<contact priority="0 . 2 ">tel : 4 03 02 02 0@home2 . net < /contact > 

<note xml : lang= "en" >This is a new tuple inserted as the 2°** tuple . </note> 
<timestamp>2 004-ll-01Tll : 49 : 29Z</timestamp> 

</tuple> 
]] > 
</add> 

<replace sel= "presence/tuple [@id= "aSO 98a . 672364762364 " ] /status/basic/text () ">closed 

</replace> 

< remove sel = "presence /dm : person [(aid= " 89898 " ] /rp : privacy " / > 
< remove sel = "presence/dm : person [(aid= " 89898 " ] /rp : activities " / > 

<replace sel= "presence/tuple [@id="a8098a . 672364762364 " ] /rp : status -icon/ text () "> 
http : //example . com/~user2/iconXYZ . gif </replace> 

</pidf-diff> 



P-Charging- Vector: The PS populates the icid parameter with a globally unique value and populates the 

identifier of its own network to the originating Inter Operator Identifier (lOI) parameter of 
this header. 

2. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.5.2.1-2 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 
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Table A.5.2.1-2: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 




scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP ps .home2 .net ;branch= 


=z9hG4bK240f34.1 


Max-Forwards: 69 




P-Charging- Vector : icid-value= "AyretyUOdm+602 IrT5tAFrbHLso=52 3 551024 " 




P- Charging -Function- Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44 


c33 :d22] ; 


ecf=[5555: :lff:2ee: 3dd: 4ee] ; ecf = [5555 : : 6aa : 7bb : Sec : 9dd] 




Route : <sip : pcscf 1 . homel . net ; lr> 




Record-Route : <sip : scscf 2 . hoTne2 . net ; l3r> 




From : 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Event : 




Contact : 




Content -Type : 




Content - Length : 




(...) 





P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter. 

P-Charging-Function-Addresses: The S-CSCF populates the F-Charging-Function- Addresses header field to be 

passed to the P-CSCF. 

3 . NOTIFY request (P-CSCF to UE) - see example in table A.5.2.1-3 

The P-CSCF forwards the NOTIFY request to the UE. 



Table A.5.2.1-3: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP pcscf 1 .homel .net;branch=240f 34 . 1, SIP/2. 0/UDP 




scscf 1 .homel .net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP ps.home2 


.net;branch=z9hG4bK348923 .1 


Max- Forwards : 68 




Record-Route : < sip : scscf 1 .homel .net; lr>, < sip : pcscf 1 .homel .net : 7531 


; lr;comp=sigcomp> 


From: 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Event : 




Contact : 




Content-Type : 




Content - Length : 




(...) 





4. 200 (OK) response (UE to P-CSCF) - see example in table A.5.2.1-4 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.5.2.1-4: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .homel .net;branch=240f 34 . 1, SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP ps .home2 .net ;branch=z9hG4bK34 8923 . 1 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



5. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.5.2.1-5 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 
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Table A.5.2.1-5: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

ps . home2 . net ;branch=z9hG4bK240f 34 . 1 
P- Access -Network- Info : 

P -Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=523 551024" 

From : 

To: 

Call-ID: 
CSeq: 

Content - Length : 



6. 200 (OK) response (S-CSCF to PS) - see example in table A.5.2.1-6 

The S-CSCF forwards the 200 (OK) response to the PS. 

Table A.5.2.1-6: 200 (OK) response (S-CSCF to PS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ps .home2 .net;branch=z9hG4bK240f 34 . 1 

P-Charging-Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=523551024" ; orig- 
ioi=homel .net : term-ioi=home2 .net 

From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The S-CSCF inserts the originating Inter Operator Identifier (lOI) parameter and populates 
the identifier of its own network to the terminating Inter Operator Identifier (lOI) parameter 
of this header. 

A.5.3 Notification to resource list in a different network and 
notification to watcher in the visited network 

A.5.3. 1 Successful notification 



Presentity Home Network 


AS(PS) 




S-CSCF#2 



Home Network of UE 



AS(RLS) S-CSCF#1 



1. NOTIFY 



4. 200 (OK) 



2. NOTIFY 



3. 200 (OK) 



5. NOTIFY 



10. 200 (OK) 



Visited Network 



P-CSCF 



6. NOTIFY 



9. 200 (OK) 



UE 



7. NOTIFY 



8. 200 (OK) 



Figure A.5.3.1-1 : Notification to resource list in a different network and 
notification to watcher in the visited network 
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Figure A.5.3.1-1 shows the PS providing presence event notification about a presentity to a RLS in a different network. 
This notification triggers the RLS to provide presence event notification to the watcher. The details of the signalling 
flows are as follows: 

1 . NOTIFY request (PS to S-CSCF) - see example in table A.5.3.1-1 

The PS determines which authorized watchers are entitled to receive presence information. For each 
appropriate watcher, the PS sends a NOTIFY request that contains the updated state of presence information. 
In this example the notification is only sent to the RLS. 

The NOTIFY request may either contain the complete set of presence information, or only those presence 
information that have changed since the last notification. In this example, the complete set of presence 
information is sent. 

Table A.5.3.1-1 : NOTIFY request (PS to S-CSCF) 



NOTIFY sip: rls.homel.net SIP/2.0 

Via: SIP/2. 0/UDP ps .home2 .net;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 70 

P-Charging- Vector : icid- value= "AyretyUOdm+602 IrT5tAFrbHLso=623551024 " ; orig- ioi=homel2 .net 
P-Charging- Function-Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Route : <sip:scscfl. homel . net ; lr> 
From : <sip : user2_publicl(ahome2 . net > ; tag=151170 
To : <sip : userl_publicl@homel . net> ; tag=31415 
Call -ID: gahjt3 93yhakfh83hfasl98a 
CSeq: 43 NOTIFY 

Subscription-State : active ;expires=5000 
Event : presence 
Contact: <sip : ps . home2 . net > 
Content-Type : application/pidf +xml 
Content -Length: (...) 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

<presence xmlns= "urn : iet f : params : xml : ns : pidf " 

xmlns : rpid= "urn : iet f : params : xml : ns : pidf : rpid" 
xmlns : dm= "urn : iet f : params : xml : ns : pidf : data -model " 
xmlns : pcp= "urn : iet f : params : xml : ns : pidf : caps " 
xmlns : c= "urn : ietf : params : xml : ns :pidf : cipid" 
entity="pres : user2_publicl@home2 . net " > 

<tuple id="a8098a. 672364762364 "> 

<status> 

<basic>open</basic> 
</status> 

<rpid : privacyx text />< /rpid : privacy> 

<rpid: status -icon>http : //example . com/ ~user2/ icon . gif< /rpid : status -icon> 
<rpid : class >sip< /rpid: class > 
<pcp : servcaps> 

<pcp : videof alse</pcp : video 
<pcp : audio>true</pcp : audio 
</pcp : servcaps> 

< contact prior ity= " . 8>sip : user2_publicl@home2 . net < /contact > 
<note xml : lang= "en" >Don ' t Disturb Please ! </note> 
<note xml : lang= " f r " >Ne derangez pas, s ' il vous plait</note> 
<timestamp>2 003-08-27T17 : 35 : 2 9Z</timestamp> 
</tuple> 

<dm:person id="438"> 

<rpid : class >presentity</ rpid : class > 
<c : homepage >http : / /example . com/~user2</c : homepage> 
<c : card>http : //example . com/ ~user2/ card . vcd</c : card> 
<rpid: activities xrpid: meeting/ >< /rpid: activities > 

<rpid: place- type until = "2003-08-27T17 : 30 : OOZ" xrpid : of f ice/ ></rpid : place- type> 
</dm:person> 
</presence> 



P-Charging- Vector: The PS populates the icid parameter with a globally unique value and 

populates the identifier of its own network to the originating Inter Operator 
Identifier (lOI) parameter of this header. 
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P-Charging-Function-Addresses: The PS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

The message body in the NOTIFY request that carries the presence information of the presentity is formed as 
indicated in RFC 3863 [21], RFC 4480 [26], draft-ietf-simple-prescaps-ext [25], RFC 4482 [32] draft-ietf- 
simple-partial-notify [24] and RFC 4479 [44]. 

2. NOTIFY request (S-CSCF to RLS) - see example in table A.5.3.1-2 

The S-CSCF#1 forwards the NOTIFY request to the RLS. 

Table A.5.3.1-2: NOTIFY request (S-CSCF to RLS) 



NOTIFY sip: rls.homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bKehuehjgt , SIP/2. 0/UDP 

scscf2 .home2 .net;branch=z9hG4bK764z87. 1, SIP/2 . 0/UDP ps.home2 .net ;branch=z9hG4bK34 8923 . 1 
Max- Forwards : 69 
P-Charging-Vector : 
P-Charging-Function-Addresses : 
Record-Route : <sip : scscf 1 .homel .net; lr> 
From: 
To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content - Type : 
Content - Length : 

(...) 



P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

and populates the identifier of its own network to the originating Inter 
Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the RLS. 

3 . 200 (OK) response (RLS to S-CSCF) - see example in table A.5.3.1-3 

The RLS generates a 200 (OK) response to the NOTIFY request. 

Table A.5.3.1-3: 200 (OK) response (RLS to S-CSCF) 



SIP/2.0 200 OK 
Via: 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=623551024" ; orig- 
ioi=homel .net : term-ioi=homel .net 

From: 
To: 

Call-ID: 
CSeq: 

Content -Length: 



P-Charging- Vector: The RLS stores the terminating Inter Operator Identifier (lOI) parameter and populates the 
identifier of its own network to the terminating Inter Operator Identifier (lOI) parameter of 
this header. 

4. 200 (OK) response (S-CSCF to PS) - see example in table A.5.3.1-4 

The S-CSCF#1 forwards the 200 (OK) response to the PS. 
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Table A.5.3.1-4: 200 (OK) response (S-CSCF to PS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ps .home2 .net ;branch=z9hG4bK348923 . 1 

P- Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=623 551024" ; orig- 
ioi=homel . net : term- ioi=homel . net 

From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter and populates 
the identifier of its own network to the terminating Inter Operator Identifier (lOI) parameter 
of this header. 

5 . NOTIFY request (RLS to S-CSCF#1) - see example in table A.5.3.1-5 

The RLS may decide to wait for other notifications and combine them in a single notification towards the UE 
or it sends the notification to the UE without any waiting. In this example, the RLS does not wait for other 
notifications. 



Table A.5.3.1-5: NOTIFY request (RLS to S-CSCF) 



NOTIFY sip : [5555 :: aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp SIP/2.0 






Via: SIP/2. 0/UDP rls .homel .net ;branch=z9hG4bK240f 34 . 1 






Max- Forwards : 70 






P-Charging- Vector : icid-value= "AyretyUOdm+602 IrT5tAFrbHLso=72 3 551024 " 


; orig-ioi=homel .net 


P- Charging -Function- Addresses : ccf=[5555::b99:c88:d7 7:ee6]; ccf 


= [5555 


: :a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : 6aa : 7bb : See : 9dd] 






Route : <sip:scscfl. homel . net ; lr> , <sip : pcscf 1 . visitedl . net ; lr> 






From: <sip:userl list lOhomel . net> ; ; tag=151170 






To : <sip : userl_publicl@homel . net> ; tag=31415 






Call -ID: gahjt3 93yhakfh83hfasl98a 






CSeq: 90 NOTIFY 






Subscription-State : active;expires=4500 






Require: eventlist 






Event : presence 






Contact: <sip : rls . homel . net > 






Content -Type : mult ipart /related; type= "application/rlmi+xml " ; 






start="<njhhsdhj@rls .homel .net>" ;boundary="70tJBfW7L78hjgfgtJPe5 


z" 


Content -Length : (...) 






--70UBfW7L78hjgfgUPe5z 






Content-Transfer-Encoding : binary 






Content -ID : <njhhsdhj®rls . homel . net> 






Content-Type : application/rlmi+xml ;charset="tJTF-8" 






<?xml version= " 1 . " encoding= "UTF- 8 " ? > 






<list xmlns= "urn : ietf : params : xml : ns : rmli " 






uri=" sip : userl list lohomel . net" 






version= " 2 " 






fullState=" false" 






<resource uri = "pres : user2_publicl(8home2 . net " > 






< name >Ko vacs Janos</name> 






<instance id="hqzsuxtfyq" state="active" cid="uhjgf dorls 


homel 


. net"/> 


</resource> 






</list> 






--70UBfW7L78hjgfgUPe5z 






Content-Transfer-Encoding : binary 






Content -ID : <uhjgf dOrls . homel . net> 






Content -Type : application/pidf +xml ;charset="UTF-8" 






<?xml version="l . 0" encoding="UTF-8 " ?> 






<presence xmlns="urn: ietf :params :xml :ns :pidf " 






xmlns : rpid="urn : ietf : params : xml : ns :pidf : rpid" 






xmlns : dm="urn : ietf : params : xml : ns :pidf : data-model " 






xmlns :pcp="urn: ietf : params :xml :ns :pidf : caps" 






xmlns : c="urn : ietf : params : xml : ns :pidf : cipid" 






entity="pres :user2_publicl@home2 .net" > 






<tuple id="a8098a. 672364762364 "> 






<status> 
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<basic>open</basic> 
</status> 

<i:pid: class >sip</rpid: class > 

<rpid : privacyxtext/ ></rpid : privacy > 

<rpid: status - icon>http : //example . com/ ~user2/ icon . gif</rpid : status -icon> 
<pcp : servcaps> 

<pcp : video>f alse</pcp : video> 
<pcp : audio>true</pcp : audio> 
</pcp : servcaps> 

<contact priority="0 .8>sip:user2_publicl@home2 . net</contact> 
<note xml : lang="en" >Don ' t Disturb Please ! </note> 
<note xml : lang=" f r" >Ne derangez pas, s'il vous plait</note> 
<timestamp>2 003 -08-27T17 : 35 : 2 9Z</timestamp> 

</tuple> 

<dm:person> 

<rpid: class>presentity</rpid: class> 
<c : homepage >http : / /example . com/~user2</c : homepage > 
<c : card>http : //example . com/~user2 /card. vcd</c : card> 
<rpid: activities xrpid: meeting/ ></rpid: activities > 

<rpid: place- type until="2003-08-27T17 : 30 : OOZ" xrpid : of f ice/ ></rpid : place- type> 
</dm:person> 

</presence> 

--70UBfW7L78hjgfgUPe5z 



P-Charging- Vector: The RLS populates the icid parameter with a globally unique value and 

populates the identifier of its own network to the originating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The RLS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

The message body in the NOTIFY request that carries the presence information of the presentity is formed as 
indicated in RFC 3863 [21], RFC 4480 [26], draft-ietf-simple-prescaps-ext [25], RFC 4482 [32] draft-ietf- 
simple-partial-notify [24] and RFC 4479 [44]. 

6. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.5.3.6 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 

Table A.5.3.1-6: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

rls . homel . net ;branch=z9hG4bK240f 34 . 1 
Max-Forwards: 69 

P-Charging- Vector : icid- value= "AyretyU0dm+6O2IrT5tAFrbHLso=723 55 1024 " 

P-Charging-Function-Addresses : 

Route : <sip : pcscf 1 . visitedl . net ; lr> 

Record-Route : <sip : scscf 1 . homel . net ; lr> 

From : 

To: 

Call-ID: 
CSeq: 

Subscription-State : 
Require : 
Event : 
Contact : 
Content -Type : 
Content - Length : 

(...) 



P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the P-CSCF. 
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7. NOTIFY request (P-CSCF to UE) - see example in table A.5.3.1-7 

The P-CSCF forwards the NOTIFY request to the UE. 



Table A.5.3.1-7: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ;comp=sigcomp 


SIP/2 . 


Via: SIP/2. O/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, 


SIP/2 . /UDP 


scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


O/UDP 


rls . homel .net ;branch=z9hG4bK24 0f 34 . 1 




Max - Forwards : 68 




Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl. 


visitedl .net : 7531; Ir ; comp=sigcomp> 


From : 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Require : 




Event : 




Contact : 




Content -Type : 




Content - Length : 




(...) 





8. 200 (OK) response (UE to P-CSCF) - see example in table A.5.3.1-8 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.5.3.1-8: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. O/UDP pcscfl .visitedl .net;branch=240f 34 . 1, 


SIP/2 . O/UDP 


scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 


O/UDP 


rls .homel .net ;branch=z9hG4bK24 0f 34 . 1 




P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content - Length : 





9. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.5.3.1-9 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.5.3.1-9: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. O/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. O/UDP 

rls .homel .net ;branch=z9hG4bK24 0f 34 . 1 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=723 551024" 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 
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10. 200 (OK) response (S-CSCF to RLS) - see example in table A.5.3.1-10 

The S-CSCF forwards the response to the RLS in the home network of the presentity. 



Table A.5.3.1-10: 200 (OK) response (S-CSCF to RLS) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP rls .homel .net;branch=z9hG4bK240f 34 . 1 




P -Access -Network- Info : 




P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=723 551024" ; 


orig- 


ioi=homel . net : term- ioi=homel . net 




P- Charging -Function -Addresses : ccf=[5555::b99:c88:d7 7:e66]; ccf=[5555: 


:a55 :b44 :c33 :d22] ; 


ecf= [5555 : : If f : 2ee : 3dd : 4ee] ; ecf= [55 55 : : 6aa : 7bb : 8cc : 9dd] 




From : 




To: 




Call-ID: 




CSeq: 




Content - Length : 





P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter 

and populates the identifier of its own network to the terminating Inter 
Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the RLS. 



A.6 PDA subscribing to his own watcher list and 

receiving notification of new watcher subscriptions 

A.6.1 Introduction 

This subclause covers the signalhng flows that show how a PUA can subscribe to his own watcher list. 
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A.6.2 PUA subscribing to watcher list and receiving a notification 
of an already pending watcher subscription followed by a 
notification of a subscription from a new watcher not already 
in the watcher list 



Visited Network 



UE (PUA) 



P-CSCF 



Home Network of UE 

AS(PS) 



S-CSCF 



1. SUBSCRIBE 



8. 200 (OK) 



11. NOTIFY 



12. 200 (OK) 



2. SUBSCRIBE 



3. Evaluation of 
Initial filter 
criteria 



7. 200 (OK) 



10. NOTIFY 



13. 200 (OK) 



4. SUBSCRIBE 



5. Autfiorlsatlon 
6. 200 (OK) 



9. NOTIFY 



14. 200 (OK) 



1 5. Watcher authorisation 



19. 200 (OK) 



17. NOTIFY 



20. 200 (OK) 



25. NOTIFY 



26. 200 (OK) 



24. NOTIFY 



27. 200 (OK) 



16. NOTIFY 



21. 200 (OK) 



22. Pending new 

watclier 
subscription 



28. 200 (OK) 



29. Watcher authorisation 



33. 200 (OK) 





31. NOTIFY 












34. 200 (OK) 







35. 200 (OK) 



Figure A.6.2-1 : PUA subscribing to watchier iist and receiving a notification 
of an already pending watcher subscription followed by a notification of a subscription 
from a new watcher not already In the watcher list 



Figure A.6.2-1 shows a PUA subscribing to the watcher list and receiving a notification of an already pending watcher 
subscription followed by a notification of a subscription from a new watcher not already in the watcher Ust. In this 
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example the default watcherinfo subscription filtering policy is applied meaning that a partial state of a watcher-info 
document is transported in the notifications. The details of the signalling flows as follows: 

1 . SUBSCRIBE request (UE to P-CSCF) - see example in table A.6.2-1 

The presentity wishes to watch his own watcher information, therefore he subscribes for the watcher 
information template-package of presence. The UE generates a SUBSCRIBE request containing the 
presence, winfo event, together with an indication of the length of time this periodic subscription should last. 

Table A.6.2-1 : SUBSCRIBE request (UE to P-CSCF) 

SUBSCRIBE sip:userl_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKehuefdam 

Max-Forwards: 70 

P-Access -Network- Info: 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=2 34151D0FCEll 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; Ir ; comp=sigcomp> , <sip : orig@scscf 1 . homel . net ; lr> 

P- Preferred- Identity : <sip : userl_publicl@homel . net> 

Privacy: none 

From : <sip : userl_publicl(ahomel . net> ; tag=31415 

To : <sip : userl_publicl@homel . net> 

Call -ID: b89rjhnedlrf jflslj40a222 

CSeq: 123 SUBSCRIBE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l- 96 ; spi-c=98765432 ; spi=87654321 ; port- 

c=8S42; port-s=7531 
Event: presence . winfo 
Expires: 7200 

Accept : application/watcherinf o+xml 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 
Content -Length: 



Request URI: Public user identity whose events the subscriber subscribes to. In this case the Public User Identity 
of the presentity in SIP URI format. 

Event: This field is populated with the value "presence. winfo" to specify the use of the watcher 

information template-package of presence. 

Accept: This field is populated with the value 'application/watcherinfo+xml' indicating that the UE 

supports this body type for notification. 

To: Same as the Request-URI. 
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2. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table A.6.2-2 

The P-CSCF looks up the serving network information for the pubHc user identity that was stored during the 
registration procedure. The SUBSCRIBE request is forwarded to the S-CSCF. A Route header is inserted 
into SUBSCRIBE request. 

Table A.6.2-2: SUBSCRIBE request (P-CSCF to S-CSCF) 



StJBSCRIBE sip :userlpublicl@homel .net SIP/2.0 

Via: SIP/2. O/tlDP pcscf 1 . visitedl .net;branch=z9hG4bK120f 34 . 1 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
P-Access-Network-Inf o : 
Max- Forwards : 69 

P-Asserted- Identity : <sip : userl_publicl@homel . net> 

P-Charging-Vector : icid-value="AyretytJ0dm+6O2IrT5tAFrbHLso=023 551024" 
Privacy : 

Route : <sip : origOscscf 1 .homel .net; lr> 
Record-Route : < sip : pcscf 1 .visitedl .net; lr> 
From: 
To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



3. Evaluation of initial filter criteria 

The S-CSCF vaUdates the service profile of this subscriber and evaluates the initial filter criteria. For 
sip:userl_publicl@homel.net the S-CSCF has originating initial Filter Criteria with Service Point Trigger of 
Method = SUBSCRIBE AND Event = "presence.winfo" that informs the S-CSCF to route the SUBSCRIBE 

request to the AS sip:ps. ho mel.net. 

4. SUBSCRIBE request (S-CSCF to PS) - see example in table A.6.2-4 

The S-CSCF forwards the SUBSCRIBE request to the PS. 

Table A.6.2-4: SUBSCRIBE request (S-CSCF to PS) 



StIBSCRIBE sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK344a65 . 1 , SIP/2. O/tTDP 
pcscf 1 .visitedl .net ;branch=z9hG4bK120f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKehuef dam 
P-Access-Network-Inf o : 
Max- Forwards : 68 

P -Asserted- Identity: <sip :userl_publicl@homel .net>, <tel:+l-212-555-llll> 

P -Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" ; orig-ioi=homel .net 
P-Charging-Function-Addresses : ccf = [5555 : :b99 :c88 :d77 :e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : Sec : 9dd] 
Privacy : 

Route: <sip :ps . homel . net ; lr> , <sip : scscfl . homel . net ; lr> 

Record-Route : < sip : scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net; lr> 

From: 

To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Accept : 
Contact : 
Content - Length : 



P-Charging- Vector: The S-CSCF inserts the originating Inter Operator Identifier (lOI) parameter 

received and populates the identifier of its own network to the originating 
Inter Operator Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the PS. 
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5. Authorization 

The PS performs the necessary authorization checks on the originator. In this example, the originator is the 
owner of the watcher information, so he/she is authorized to see the full watcher information. 

In other examples (when the originator is not the owner of the watcher information) subscribers are only 
allowed to monitor the state of their own subscription, which means that they will receive notifications only 
containing the state of their own subscription. This requires that a terminating initial Filter Criteria with 
Service Point Trigger of Method = SUBSCRIBE AND Event = "presence.winfo" has been defined for the 
user sip : user 1 _publicl @ home! .net. 

6. 200 (OK) response (PS to S-CSCF) - see example in table A.6.2-6 

The PS sends the response to the S-CSCF. 

Table A.6.2-6: 200 (OK) response (PS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK344aG5 . 1 , SIP/2. 0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK12 0f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ;branch=z9hG4bKehuef dam 
P- Charging -Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" ; orig- 

ioi=homel . net : term- ioi=homel . net 
P-Charging- Function-Addresses : ccf = [5555: :b9 9:c88:d7 7:e6G] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Record-Route : 
From : 

To : <sip : userl_publicl@homel . net> ; tag=151170 

Call-ID: 
CSeq: 
Expires : 

Contact: <sip : ps . homel . net> 
Content -Length: 



P-Charging- Vector: The PS stores the originating Inter Operator Identifier (lOI) parameter and 

populates the identifier of its own network to the terminating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Cliarging-Function-Addresses: The PS stores the P-Charging-Function-Addresses header field and passes 

this header to the S-CSCF. 

7. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.6.2-7 

The S-CSCF forwards the response to the P-CSCF. 

Table A.6.2-7: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl .net ;branch=z9hG4bK120f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKehuef dam 
P-Charging -Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Expires : 
Contact : 
Content - Length : 



P-Charging- Vector: The S-CSCF stores the terminating Inter Operator Identifier (lOI) parameter. 
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8. 200 (OK) response (P-CSCF to UE) - see example in table A.6.2-8 

The P-CSCF forwards the response to the PUA in the UE. 



Table A.6.2-8: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] 


: 1357 ; comp=sigcomp ;branch=z9hG4bKehuef dam 


Record-Route : <sip : orig@scscf 1 .homel .net 


; lr>, <sip :pcscf 1 .homel .net : 7531 ; Ir ; comp=sigcomp> 


From: 




To: 




Call-ID: 




CSeq: 




Expires : 




Contact : 




Content - Length : 





9. NOTIFY request (PS to S-CSCF) - see example in table A.6.2-9 

After the PS generated a 200 (OK) response to the SUBSCRIBE request from the UE, it generates a NOTIFY 
request containing the current state of the watcher information. The watcher information contains one 
pending subscription. 

Table A.6.2-9 NOTIFY request (PS to S-CSCF) 



NOTIFY sip : [5555 :: aaa :bbb : CCC : ddd] : 1357 ;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP ps .homel .net;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 70 

P-Charging-Vector : icid-value= "AyretyUOdm+602 IrT5tAFrbHLso=12 3 551024 " ; 
P- Charging -Function- Addresses : ccf=[5555::b99:c88:d7 7:e66]; ccf=[5555: 

ecf= [5555 : : If f : 2ee : 3dd : 4ee] ; ecf= [5555 : : 6aa: 7bb: 8cc : 9dd] 
Route : <sip : scscf 1 . homel . net ; lr> , <sip : pcscf 1 . visitedl . net ; lr> 
From: <sip : userl_publicl(ahomel . net > ; tag=15117 
To : <sip : userlpubliclohomel . net> ; tag=31415 
Call -ID: b8 9rjhnedlrf jf Islj4 0a222 
CSeq: 89 NOTIFY 

Subscription-State : active ;expires=72 00 
Event: presence . winfo 
Contact: <sip :ps . homel . net> 
Content-Type : application/watcherinf o+xml 
Content -Length: (...) 

<?xml version= " 1 . " ? > 

<watcherinf o xmlns="urn: ietf :params :xml :ns :watcherinfo" 
version="0" state= " f ull " > 
<watcher-list resource= " sip : userl_publicl(ahomel . net " package= "presence " > 
<watcher id="77ajsyy76" event=" subscribe" 

status= "pending" >sip :user2_publicl®home2 . net</watcher> 
< /watcher- list > 
< /watcherinf o> 



orig- ioi=homel .net 
:a55 :b44 :c33 :d22] ; 



P-Charging- Vector: The PS populates the icid parameter with a globally unique value and 

populates the identifier of its own network to the originating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The PS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

10. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.6.2-10 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 
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Table A.6.2-10: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

ps . homel . net ;branch=z9hG4bK240f 34 . 1 
Max-Forwards: 69 

P-Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123 551024" 

P-Charging-Function-Addresses : 

Route : <sip : pcscf 1 . visitedl . net ; lr> 

Record-Route : <sip:scscfl .homel .net ,- lr> 

From: 

To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content -Type : 
Content - Length : 

(...) 



P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

received. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the P-CSCF. 

11. NOTIFY request (P-CSCF to UE) - see example in table A.6.2-11 

The P-CSCF forwards the NOTIFY request to the PUA in the UE. 



Table A.6.2-11 : NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555 :: aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp 


SIP/2 . 




Via: SIP/2. 0/UDP pcscf 1 .visitedl .net ;branch=240f 34 . 1 , 


SIP/2 . 0/UDP 




scscf 1 .homel . net ; branch=z9hG4bK351g45 . 1, SIP/2 


0/UDP ps.home2 


. net ; branch=z9hG4bK34 8923 . 1 


Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl. 


homel .net : 7531 


; Ir ; comp=sigcomp> 


Max- Forwards : 68 






From : 






To: 






Call-ID: 






CSeq: 






Subscription-State : 






Event : 






Contact : 






Content -Type : 






Content - Length : 






(...) 







12. 200 (OK) response (UE to P-CSCF) - see example in table A,6.2-12 

The PUA on the UE determines that this is a full state watcher-info document and replaces any current 
watcher-info with the new document. The UE acknowledges the NOTIFY request with a 200 (OK) response 
to the P-CSCF. 

Table A.6.2-12: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 


scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 


0/UDP ps .home2 .net ;branch=z9hG4bK34 8923 . 1 


P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 
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13. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.6.2-13 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.6.2-13: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

ps . homel . net ;branch=z9hG4bK240f 34 . 1 
P -Access -Network- Info : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123 551024" 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



14. 200 (OK) response (S-CSCF to PS) - see example in table A.6.2-14 

The P-CSCF forwards the response to the PS in the home network of the UE. 

Table A.6.2-14: 200 (OK) response (S-CSCF to PS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ps .homel .net;branch=z9hG4bK240f 34 . 1 
P-Access-Network-Inf o : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" ; orig- 
ioi=homel .net : term-ioi=homel .net 

From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The S-CSCF inserts the terminating Inter Operator Identifier (lOI) parameter received and 
populates the identifier of its own network to the terminating Inter Operator Identifier (101) 
parameter of this header. 

1 5 . Authorization of watcher 

The presentity determines to allow the watcher to access the presence information. The PUA modifies the 
subscription authorization poUcy by authorizing presence information for sip:user2_pubUc l@homel.net. 
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16. NOTIFY request (PS to S-CSCF) - see example in table A.6.2-16 

The authorization event means changes in the watcher information, which triggers a new NOTIFY request. 
The watcher information included in the NOTIFY request contains only information on the watcher whose 
state has changed, which in this example is the accepted subscription of sip:user2_publicl@homel.net. 



Table A.6.2-16: NOTIFY request (PS to S-CSCF) 



iMU 1 ±r i Sip : L -3 -3 -3 -3 : : 0.0.0. : uou : ccc : aaaj : ± j o / ; conip=sxgconip c^xf / z . u 




Via* c;tP/9 n /TTDP nd "hmnicil nicil- • hr-anr-l-i — 7 Ql-in^-hTf 94. +^"5 4. 1 
vXO.* jJ.c/^,yj/\J±jtr Ud. llUlLLc: X . lie: L. / iJ.L 0.11L>11 — ^ ^ 1 L\j'± U *± U J- J r± . X 




M3.X — Fo]fW3.]fds ! "7 




P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=2 2 3 551024" ; 


orig-ioi=homel .net 


P-Charging-Function-Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : 


:a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 




Route : <sip : scscf 1 .homel .net ;lr>, <sip :pcscf 1 . visitedl .net; lr> 




From: <sip : userl_publicl@homel . net >; tag=15 1170 




To : <sip :userl_publicl .homel .net>; tag=31415 




Call -ID: b89rjhnedlrf jflslj4 0a222 




CSeq: 90 NOTIFY 




Subscript ion- State : active ;expires=4 900 




Event : presence . winf o 




Contact: <sip :ps . homel . net> 




Content-Type : application/watcherinf o+xml 




Content -Length: (...) 




<?xml version="l . 0" ?> 




<watcherinfo xmlns="urn: ietf :params :xml :ns : watcherinf o" 




version="0" state= "partial " > 




<watcher-list resource="sip :userl_publicl®homel .net" package= "presence" > 


<watcher id="77ajsyy76" event=" subscribe" 




status=" active" >sip :user2_publicl@home2 . net < /watcher > 




< /watcher- list> 




< /watcherinf o> 





P-Charging- Vector: The PS populates the icid parameter with a globally unique value and 

populates the identifier of its own network to the originating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The PS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

17. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.6.2-17 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 



Table A.6.2-17: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 


0/UDP 


ps . homel .net ;branch=z9hG4bK240f 34 . 1 




Max - Forwards : 69 




P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223 551024" 


P-Charging-Function-Addresses : ccf=[5555: : b99 : c88 : d77 : e66] ; ccf= 


[5555 : :a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 




Route : < sip :pcscfl .visitedl . net ; lr> 




Record-Route : <sip : scscf 1 .homel .net; lr> 




From: 




To: 




Call-ID: 




CSeq: 




Subscription-State : 




Event : 




Contact : 




Content -Type : 




Content - Length : 




(...) 





P-Charging- Vector: The S-CSCF passes this header received. 
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P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the P-CSCF. 

18. NOTIFY request (P-CSCF to UE) - see example in table A.6.2-18 

The P-CSCF forwards the NOTIFY request to the PUA in the UE. 



Table A.6.2-18: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp 


SIP/2 . 




Via: SIP/2. O/tlDP pcscf 1 . visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 




scscf 1 .homel .net ;branch=z9hG4bK351g45 . 1 , SIP/2 . 


0/UDP ps.home2 


.net;branch=z9 hG4 bK3 48923.1 


Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl. 


homel .net : 7531 


; lr;comp=sigcomp> 


Max- Forwards : 68 






From: 






To: 






Call-ID: 






CSeq: 






Subscription-State : 






Event : 






Contact : 






Content-Type : 






Content - Length : 






(...) 







19. 200 (OK) response (UE to P-CSCF) - see example in table A.6.2-19 

The PUA determines that this is a full state watcher-info document and replaces any current watcher-info 
with the new document. The UE acknowledges the NOTIFY request with a 200 (OK) response to the P- 
CSCF. 



Table A.6.2-19: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/tIDP pcscf 1 . visitedl . net ;branch=240f 34 . 1 , 


SIP/2 .0/UDP 


scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 


0/UDP ps .home2 .net ;branch=z9hG4bK34 8923 . 1 


P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content -Length: 





20. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.6.2-20 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.6.2-20: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/tIDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/tIDP 

ps .homel .net ;branch=z9hG4bK24 0f 34 . 1 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223 551024" 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



ETSI 



3GPP TS 24.141 version 8.2.0 Release 8 108 ETSI TS 124 141 V8.2.0 (2008-10) 



21 . 200 (OK) response (S-CSCF to PS) - see example in table A.6.2-21 

The P-CSCF forwards the response to the PS in the home network of the UE. 

Table A.6.2-21 : 200 (OK) response (S-CSCF to PS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ps .homel .net;branch=z9hG4bK240f 34 . 1 
P -Access -Network- Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223 551024" ; orig-ioi=homel .net 
term- ioi=visitedl .net 

From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The PS inserts the originating Inter Operator Identifier (lOI) parameter received 

and.populates the identifier of its own network to the terminating Inter Operator Identifier 
(lOI) parameter of this header. 

22. Pending new watcher subscription 

The PS receives a SUBSCRIBE request from a new watcher and performs the necessary authorization checks 
on the originator and determines that this is a new watcher that is not yet in the watcher hst. 

23 . NOTIFY request (PS to S-CSCF) - see example in table A.6.2-23 

The PS generates a NOTIFY request containing watcher information of the new watcher pending 
subscription. Thus, the watcher information contains the partial state. 

Table A.6.2-23 NOTIFY request (PS to S-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP ps .homel .net;branch=z9hG4bK240f 34 . 1 
Max- Forwards : 70 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323 551024" ; orig-ioi=homel .net 
P-Charging-Function-Addresses : ccf = [5555 : :b99 :c88 :d77 :e66] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Route : <sip : scscf 1 .homel .net; lr>, <sip :pcscf 1 . visitedl .net; lr> 
From: < sip : userl_publicl@homel . net >; tag=15 1170 
To : <sip :userl_publicl .homel .net>; tag=31415 
Call -ID: b89rjhnedlrf jflslj4 0a222 
CSeq: 90 NOTIFY 

Subscript ion- State : active ;expires=5000 
Event : presence . winf o 

Content-Type : application/watcherinf o+xml 
Contact: <sip : ps . homel . net ; lr> 
Content -Length: (...) 

<?xml version=" 1 . " ?> 

<watcherinfo xmlns="urn: ietf :params :xml :ns : watcherinf o" 
version="0" state= "partial " > 
<watcher-list resource="sip :userl_publicl@homel .net" package^ "presence" > 
<watcher id="34bytzx54" event=" subscribe" 

status= "pending" >sip :user3_publicl@home3 . net < /watcher > 
< /watcher- list> 
< /watcherinf o> 



P-Charging- Vector: The PS populates the icid parameter with a globally unique value and 

populates the identifier of its own network to the originating Inter Operator 
Identifier (101) parameter of this header. 

P-Charging-Function-Addresses: The PS populates the P-Charging-Function-Addresses header field to be 

passed to the S-CSCF. 

24. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.6.2-24 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 
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Table A.6.2-24: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

ps . homel . net ;branch=z9hG4bK240f 34 . 1 
Max-Forwards: 69 

P-Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323 551024" 

P-Charging-Function-Addresses : 

Route : <sip : pcscf 1 . visitedl . net ; lr> 

Record-Route : <sip:scscfl .homel .net ,- lr> 

From: 

To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Cont ent - Type : 
Contact : 
Content - Length : 

(...) 



P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

received. 

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the P-CSCF. 

25. NOTIFY request (P-CSCF to UE) - see example in table A.6.2-25 

The P-CSCF forwards the NOTIFY request to the PUA in the UE. 



Table A.6.2-25: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555 :: aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp 


SIP/2 . 




Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=240f 34 . 1 


SIP/2 .0/UDP 




scscf 1 . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2 


0/UDP ps.home2 


.net;branch=z9hG4bK348923 .1 


Max- Forwards : 68 






Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl 


homel .net : 7531 


; lr;comp=sigcomp> 


From : 






To: 






Call-ID: 






CSeq: 






Subscription-State : 






Event : 






Content - Type : 






Contact : 






Content - Length : 






(...) 







26. 200 (OK) response (UE to P-CSCF) - see example in table A,6.2-26 

The PUA determines that this is a partial state notification of watcher-info and adds the new pending 
subscription to its existing watcher-info document. The UE acknowledges the NOTIFY request with a 200 
(OK) response to the P-CSCF. 

Table A.6.2-26: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/UDP 


scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 


0/UDP ps .home2 .net ;branch=z9hG4bK34 8923 . 1 


P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 
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27. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.6.2-27 
The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.6.2-27: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

ps . homel . net ;branch=z9hG4bK240f 34 . 1 
P -Access -Network- Info : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323 551024" 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



28. 200 (OK) response (S-CSCF to PS) - see example in table A.6.2-28 

The P-CSCF forwards the response to the PS in the home network of the UE. 

Table A.6.2-28: 200 (OK) response (S-CSCF to PS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ps .homel .net;branch=z9hG4bK240f 34 . 1 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323 551024" ; orig-ioi=homel .net ; 
term-ioi=visitedl .net 

From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 



P-Charging- Vector: The S-CSCF insertes the originating Inter Operator Identifier (lOI) parameter received and 
populates the identifier of its own network to the terminating Inter Operator Identifier (lOI) 
parameter of this header. 

29 . Authorization of watcher 

The presentity determines to allow the watcher to access the presence information. The PUA modifies the 
authorization pohcy by authorizing presence information for sip:user3_pubUcl@home3.net. 



ETSI 



3GPP TS 24.141 version 8.2.0 Release 8 



111 



ETSI TS 124 141 V8.2.0 (2008-10) 



30. NOTIFY request (PS to S-CSCF) - see example in table A.6.2-30 

The authorization event means changes in the watcher information, which triggers a new NOTIFY request. 
The watcher information included in the NOTIFY request contains the accepted subscription of 
sip:user3_publicl @home3.net. 



Table A.6.2-30 NOTIFY request (PS to S-CSCF) 



iMU 1 ±r 1 Sip : L -3 -3 -3 -3 : : 0.0.0. : uoo : ccc : aaaj : ± j o / ; conip=sxgconip is^tr / a . u 




Via* c;tP/9 n /TTDP nd "hmnicil nicil- • hr-anr-l-i — 7 Ql-in^-hTf 94. +^"5 4. 1 

VXO.* O-Llr/^.U/UUlr UD. llUlLLc: X . lie: L. / iJ-L 0.11L>11 — ^ 7110r± iJIS.^ *± U J- J r± . X 




M3.X — Fo]fW3.]fds ! "7 




P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=42 3 551024" ; 


orig-ioi=homel .net 


P-Charging-Function-Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : 


:a55 :b44 :c33 :d22] ; 


ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 




Route : <sip : scscf 1 .homel .net ;lr>, <sip :pcscf 1 . visitedl .net; lr> 




From: <sip : userl_publicl@homel . net >; tag=15 1170 




To : <sip :userl_publicl .homel .net>; tag=31415 




Call -ID: b89rjhnedlrf jflslj4 0a222 




CSeq: 90 NOTIFY 




Subscript ion- State : active ;expires=4 900 




Event : presence . winf o 




Content-Type : application/watcherinf o+xml 




Contact: <sip :ps . homel . net ; lr> 




Content -Length: (...) 




<?xml version="l . 0" ?> 




<watcherinfo xmlns="urn: ietf :params :xml :ns : watcherinf o" 




version="0" state= "partial " > 




<watcher-list resource="sip :userl_publicl®homel .net" package= "presence" > 


<watcher id="34bytzx54" event=" subscribe" 




status=" active" >sip :user3_publicl@home3 . net < /watcher > 




< /watcher- list> 




< /watcherinf o> 





P-Charging- Vector: The PS populates the icid parameter with a globally unique value and 

populates the identifier of its own network to the originating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The PS populates the P-Charging-Function- Addresses header field to be 

passed to the S-CSCF. 

3 1 . NOTIFY request (S-CSCF to P-CSCF) - see example in table A.6.2-31 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 

Table A.6.2-31 : NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

ps .homel .net ;branch=z9hG4bK24 0f 34 . 1 
Max- Forwards : 69 

P -Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423 551024" 

P-Charging-Function-Addresses : 

Route : < sip :pcscfl .visitedl . net ; lr> 

Record-Route : <sip : scscf 1 .homel .net; lr> 

From: 

To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Content -Type : 
Contact : 
Content - Length : 

(...) 



P-Charging- Vector: The S-CSCF stores the originating Inter Operator Identifier (lOI) parameter 

received. 
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P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and 

passes this header to the P-CSCF. 

32. NOTIFY request (P-CSCF to UE) - see example in table A.6.2-32 

The P-CSCF forwards the NOTIFY request to the PUA in the UE. 



Table A.6.2-32: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp 


SIP/2 . 




Via: SIP/2. 0/tIDP pcscf 1 . visitedl .net;branch=240f 34 . 1, 


SIP/2 . 0/tJDP 




scscf 1 .homel .net ;branch=z9hG4bK351g45 . 1 , SIP/2 . 


0/UDP ps.home2 


.net;branch=z9hG4bK348923 .1 


Max- Forwards : 68 






Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip:pcscfl. 


homel .net : 7531 


; lr;comp=sigcomp> 


From: 






To: 






Call-ID: 






CSeq: 






Subscription-State : 






Event : 






Content-Type : 






Contact : 






Content - Length : 






(...) 







33. 200 (OK) response (UE to P-CSCF) - see example in table A.6.2-33 

The PUA determines that this is a partial state notification of watcher-info and updates the active subscription 
to its existing watcher-info document. The UE acknowledges the NOTIFY request with a 200 (OK) response 
to the P-CSCF. 

Table A.6.2-33: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/tIDP pcscf 1 . visitedl . net ;branch=240f 34 . 1 , 


SIP/2 .0/UDP 


scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 


0/UDP ps .home2 .net ;branch=z9hG4bK34 8923 . 1 


P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id- 


3gpp=234151D0FCEll 


From: 




To: 




Call-ID: 




CSeq: 




Content -Length: 





34. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.6.2-34 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.6.2-34: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/tIDP 

ps .homel .net ;branch=z9hG4bK24 0f 34 . 1 
P-Access-Network-Inf o : 
From: 
To: 

Call-ID: 
CSeq: 

Content - Length : 
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35. 200 (OK) response (S-CSCF to PS) - see example in table A.6.2-35 

The P-CSCF forwards the response to the PS in the home network of the UE. 

Table A.6.2-35: 200 (OK) response (S-CSCF to PS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ps .homel .net;branch=z9hG4bK240f 34 . 1 

P-Access-Network-Inf o : 

From: 

To: 

Call-ID: 
CSeq: 

Content - Length : 



A.7 PNA subscription for the reg-event package 

Figure A.7-1 shows the registration signalUng flow for the scenario when the user is not registered. For the purpose of 
this registration signalling flow, the subscriber is considered to be roaming. This signalhng flow also shows the 
authentication of the private user identity. 

This is followed by the subscription procedure for the reg-event package, whereby the PNA requests to be notified by 
the S-CSCF when a registration event has occurred. This is done using the 'reg-event' package as described in 
3GPPTS 24.229 [9]. 
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Figure A.7-1: Registration signalling: user not registered 
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1-22. See 3GPP TS 24.228 [8], subclause 6.2 steps 1 through 22 

23. Initial filter criteria 

The S-CSCF analyses the incoming request against the initial filter criteria and decides to send a third-party 
REGISTER request to the PNA. 

24. REGISTER request (S-CSCF to PNA) - see example in table A.7-24 

This signalUng flow forwards the REGISTER request from the S-CSCF to the PNA. 

Table A.7-24: REGISTER request (S-CSCF to PNA) 



REGISTER sip: ps.homel.net SIP/2.0 
Via: SIP/2. 0/UDP sip:scscfl. homel.net 

Max-Forwards: 70 
P-Access-Network-Info : 
P-Visited-Network-ID : 
P-Charging-Vector : 
P-Charging-Function-Addresses : 
From: sip : scscf 1 . homel . net 
To : <sip : userl_publicl@homel . net> 
Contact: <sip : scscf 1 .homel .net> 
Expires: 600000 

Call-ID: apb03a0s09dkjdfglkj49112 
CSeq: 43 REGISTER 
Content -Length: 



25 . 200 OK response (PNA to S-CSCF) - see example in table A.7-25 

The PNA sends a 200 (OK) response to the S-CSCF indicating that Registration was successful. 

Table A.7-25: 200 OK response (PNA to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP sip : scscf 1 . homel .net 

From: 

To: 

Call-ID: 

Contact : <sip: scscf 1 .homel .net>;expires=600000 
CSeq: 

Date: Wed, 11 July 2001 08:49:37 GMT 
Content-Length : 



26. SUBSCRIBE request (PNA to S-CSCF) - see example in table A.7-26 

The PNA sends the SUBSCRIBE request for the reg event package. 

Table A.7-26: SUBSCRIBE request (PNA to S-CSCF) 



SUBSCRIBE sip:userlj>ublicl@homel .net SIP/2.0 
Via: SIP/2. 0/UDP sip:ps .homel .net 
Max- Forwards : 70 

P-Asserted- Identity: <sip :ps .homel .net> 
Privacy: none 

From: <sip :ps .homel .net>; tag=31415 
To: <sip:userl_publicl®homel .net> 
Call -ID: dre36d2v32gnlgiiomm72445 
CSeq: 61 SUBSCRIBE 
Event : reg 
Expires: 600000 

Accept: application/reginf o+xml 
Contact: <sip:ps .homel .net> 
Content -Length: 



From: This header is populated with the SIP URI that identifies the PNA. 

Contact: This is where the NOTIFY requests for this subscription will be sent. 
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Event: This field is set to the value 'reg' to specify the use of the reg event package. 

Accept: This field is set to the value "application/reginfo+xml". 

27. 200 (OK) response (S-CSCF to PNA) - see example in table A.7-27 

The S-CSCF sends a 200 (OK) response to the PNA indicating that registration was successful. 

Table A.7-27: 200 (OK) response (S-CSCF to PNA) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP sip : ps . homel . net 
P-Asserted- Identity: <sip: scscf 1 . homel .net> 
Privacy: 
From: 

To: <sip:userl j)ublicl@homel .net>; tag=151170 

Call-ID: 

CSeq: 

Contact: <sip : scscf 1 . homel .net> 
Expires : 
Content -Length: 



Expires: If value of the Expires header in SUBSCRIBE request is different from the one received in REGISTER 
method, then the value of Expires header in the 200 (OK) response is set to match the value of Expires 
header in REGISTER method. 

28. NOTIFY request (S-CSCF to PNA) - see example in table A.7-28 

The S-CSCF sends a first NOTIFY request towards the PNA in order to inform the PNA about the 
registration status of monitored user. 



Table A.7-28: NOTIFY request (S-CSCF to PNA) 



NOTIFY sipipcscfl. visitedl.net SIP/2.0 




Via: SIP/2. 0/UDP scscf 1. homel. net ;branch=z9hG4bK332b23.1 




Max- Forwards : 70 




From : <sip : userl_publicl®homel . net > ; tag=151170 




To : <sip : userl_publicl@pcscf 1 . visitedl .net> ; tag=31415 




Call-ID : dre36d2v32gnlgiiomm72445 




CSeq: 42 NOTIFY 




Subscript ion- State : active ; expires=6 00000 




Event : reg 




Content-Type : application/reginfo+xml 




Contact: <sip : scscf 1 . homel .net> 




Content -Length: (...) 




<?xml version="l . 0"?> 




<reginf o xmlns= "urn : ietf :params :xml :ns : reginf o" 




version="l" state= " full " > 




<registration aor="sip:userl publicl@homel .net" id="a7" 


state="active"> 


<contact id="76" state="active" event=" registered" > 




<uri>sip: [5555 : : aaa :bbb : ccc : ddd] </uri> 




</contact> 




</registration> 




<registration aor="sip:userl_public2@homel .net" id="a8" 


state="active"> 


<contact id="77" state="active" event=" created" > 




<uri>sip: [5555 : : aaa :bbb : ccc : ddd] </uri> 




</contact> 




</registration> 




<registration aor="tel : +358504821437" id="a9" state="active"> 


<contact id="78" state="active" event=" created" > 




<uri>sip: [5555 : : aaa :bbb : ccc : ddd] </uri> 




</contact> 




</registration> 




</reginf o> 





From: The tag of this field matches that of the To; field in the received 200 (OK) response for the 

SUBSCRIBE request. 
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Content- Type: Set to the value of the Accept header received in the SUBSCRIBE request or 

"appHcation/reginfo+xml" if the Accept header was not present in the SUBSCRIBE request. 

The message body in the NOTIFY request that carries the subscriber's registration state is formed as 
indicated in 3GPP TS 24.229 [9]. 

29. 200 (OK) response (PNA to S-CSCF) - see example in table A.7-29 

PNA sends the 200 (OK) response to the S-CSCF. 

Table A.7-29: 200 (OK) response (PNA to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23.1 

From : 

To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length: 



A.8 Example signalling flows of HTTP based presence 
service operation 

A.8.1 Introduction 

This subclause shows signalling flows relating to the manipulation of presence service data over the Ut reference point 
using XCAP. The flows only shows the signalling between the XCAP server and the XCAP cUent, thus possible proxies 
located in between the entities are not shown in the example signalling flows. 

Each example signalling flow shows several sequences of manipulation of data for the presence service. 

NOTE: Error conditions are not considered in the examples e.g. if authorization checks fail in the XCAP server, 
XML Schema compliancy checks fail or the file specified by the URI does not exist then an appropriate 
4xx response is sent to the client. 

Clarifications how XCAP is using HTTP are described in RFC 4825 [33]. 

NOTE: The authentication proxy resides between UE (XCAP client) and AS (XCAP server), and examples of 
signalling flows for the authentication proxy are provided in 3GPP TS 24.109 [7]. 



ETSI 



3GPP TS 24.141 version 8.2.0 Release 8 



118 



ETSI TS 124 141 V8.2.0 (2008-10) 



A.8.2 Signalling flows demonstrating how XCAP clients 
manipulate resource lists 



UE (XCAP AS (XCAP 
client) server) 




1 . XCAP PUT 




► 

^ 2. XCAP 201 (Created) 


3. XCAP PUT 


► 

4. XCAP 200 (OK) 

-4 


5. XCAP DELETE 
► 


^ 6. XCAP 200 (OK) 


7. XCAP GET 


► 

^ 8. XCAP 200 (OK) 





Figure A.8.2-1 : XCAP client manipulating a resource list on XCAP server 

Figure A.8.2-1 shows a how a XCAP client may manipulate a resource list on a XCAP server. The details of the 
signalling flows are as follows: 

1 . XCAP PUT request (XCAP client to XCAP server - see example in table A.8.2-1 

The XCAP client generates an XCAP PUT request to create a new resource list on the XCAP server. The 
resource list has one entry. 



Table A.8.2-1 : XCAP PUT request (XCAP client to XCAP server) 



PUT http : //xcap.homel .net /services /resource -lists /users /user 1/pf .xml 


HTTP/1 . 1 


User-Agent : IMS subscriber 




Date: Thu, 08 Jan 2004 10:13:17 GMT 




Content-Type : application/resource-lists+xml 




Content -Length: (...) 




<?xml version="l . 0" encoding="UTF-8"?> 




<resource- lists xmlns= "urn: ietf :params :xml :ns : resource -lists " > 




xmlns :xsi="http: / /www.w3 .org/2001/XMLSchema-instance" 




xsi : schemaLocation= "urn : ietf :params :xml :ns : resource -11. 


3tS"> 


<list name=" Presence fellows"> 




< entry uri= "sip :user2_publicl@home2 .net " > 




<di splay-name >User2</display-name> 




</entry> 




</list> 




< /resource- list s> 
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2. XCAP 201 (Created) response (XCAP server to XCAP client) - see example in table A.8.2-2 

After the XCAP server has performed the necessary authorization checks on the originator to ensure the 
XCAP cUent is allowed to create a file, the XCAP server sends an XCAP 201 (Created) response to the 
XCAP client. 

Table A.8.2-2: XCAP 201 (Created) response (XCAP server to XCAP client) 



HTTP/1.1 201 Created 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Etag: "aaa" 

Date: Thu, 08 Jan 2004 10:50:35 GMT 
Content -Length: 



3. XCAP PUT request (XCAP client to XCAP server) - see example in table A.8.2-3 

The XCAP client adds a new entry to the previously created resource list by generating a new XCAP PUT 
request. 

Table A.8.2-3: XCAP PUT request (XCAP client to XCAP server) 



PUT http: //xcap.homel .net /services /resource -lists /users /user 1/pf .xml/~~/resource- 

lists/list%5b@name=%22Presence_f ellows%22%5d/entry HTTP/1 . 1 
User-Agent : IMS subscriber 
Date: Thu, 08 Jan 2004 10:13:17 GMT 
Content-Type: application/xcap-el 
Content -Length: (...) 

<entry uri="sip:user3_publicl@home3 .net"> 

<display-name>User3</display-name> 
< /entry > 



4. XCAP 200 (OK) response (XCAP server to XCAP cUent) - see example in table A.8.2-4 

After the XCAP server has performed the necessary authorization checks, XML document validations and 
XML schema compliancy checks the XCAP server sends an XCAP 200 (OK) response to the XCAP client. 

Table A.8.2-4: XCAP 200 (OK) response (XCAP server to XCAP client) 



HTTP/1.1 200 OK 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Etag: "aab" 

Date: Thu, 08 Jan 2004 10:50:45 GMT 
Content -Length: 



5 . XCAP DELETE request (XCAP cUent to XCAP server) - see example in table A.8.2-5 

The XCAP client decides to delete the entry "user2" from the resource list. The XCAP client generates an 
XCAP DELETE request. 

Table A.8.2-5: XCAP DELETE request (XCAP client to XCAP server) 



DELETE http : //xcap .homel .net /services /resource -lists /users /userl/pf .xml/ — /resource - 

lists/list %5b@name=%22Presence_fellows%22%5d/entry%5b@name=user2"%5d HTTP/1 . 1 
Host: oper .example . com: 9999 
User-Agent : IMS subscriber 
Date: Thu, 08 Jan 2004 10:14:17 GMT 



ETSI 



3GPP TS 24.141 version 8.2.0 Release 8 



120 



ETSI TS 124 141 V8.2.0 (2008-10) 



6. XCAP 200 (OK) response (XCAP server to XCAP client) - see example in table A.8.2-6 

After the XCAP server has performed the necessary authorization checks on the originator to ensure the 
XCAP cUent is allowed to delete an entry from the resource list, the XCAP server sends an XCAP 200 (OK) 
response. 

Table A.8.2-6: XCAP 200 (OK) response (XCAP server to XCAP client) 



HTTP/1.1 200 OK 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Date: Thu, 08 Jan 2004 11:00:47 GMT 
Content -Length: 



7. XCAP GET request (XCAP client to XCAP server) - see example in table A.8.2-7 

The XCAP client wishes to check the result of the previous transaction by generating an XCAP GET request. 

Table A.8.2-7: XCAP GET request (XCAP client to XCAP server) 



GET http : //xcap . homel . net /services/resource- list s/users/userl/pf . xml HTTP/1 . 1 

User-Agent : IMS subscriber 

Date: Thu, 08 Jan 2004 11:13:17 GMT 

Content -Length: 



8. XCAP 200 (OK) response (XCAP server to XCAP cUent) - see example in table A.8.2-8 

After the XCAP server has performed the necessary authorization checks on the originator to ensure the 
XCAP cUent is allowed to fetch the resource Ust, the XCAP server sends an XC/U' 200 (OK) response to the 
XCAP client including the resource list in the body of the response. 

Table A.8.2-8: XCAP 200 (OK) response (XCAP server to XCAP client) 



HTTP/1.1 200 OK 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Etag : " askda j dsa j " 

Date: Thu, 08 Jan 2004 11:50:35 GMT 
Content -Type : application/resource -list s+xml 
Content -Length: (...) 

<?xml version="l . 0" encoding="UTF-8"?> 

<resource- lists xmlns= "urn : ietf :params :xml :ns : resource -lists " > 

xmlns :xsi="http: //www.w3 .org/2001/XMLSchema-instance" 
xsi : schemaLocation= "urn : ietf :params :xml :ns : resource -lists " > 
<list name="Presence_fellows"> 

<entry uri="sip:user3_publicl@home3 .net"> 

<display-name>User3</display-name> 
</entry> 
</list> 
</resource-lists> 
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A.8.3 Signalling flows demonstrating how XCAP clients 
manipulate presence authorization policy 



UE (XCAP AS (XCAP 
client) server) 




1 . XCAP PUT 




► 

^ 2. XCAP 201 (Created) 


3. XCAP PUT 


► 

^ 4. XCAP 200 (OK) 


5. XCAP DELETE 


► 

^ 6. XCAP 200 (OK) 


7. XCAP GET 


► 

^ 8. XCAP 200 (OK) 





Figure A.8.3-1 : XCAP client manipulating presence authorization policy on XCAP server 

Figure A.8.3-1 shows a XCAP client manipulating presence authorization policy on a XCAP server. The details of the 
signalling flows are as follows: 

1 . XCAP PUT request (XCAP client to XCAP server) - see example in table A.8.3-1 

The XCAP client generates an XCAP PUT request to create a presence authorization policy on the XCAP 
server. The presence authorization poUcy has one rule allowing for sip:user2_public l@home2.net to see all 
service information along with the service related servcaps elements defined in draft-ietf-simple-prescaps- 
ext [25]. 

Table A.8.3-1 : XCAP PUT request (XCAP client to XCAP server) 



PUT http : //xcap . homel . ne t/ service s/pres- rules /users /user 1/ps . xml HTTP/1 . 1 

User-Agent : IMS subscriber 

Date: Thu, 08 Jan 2004 10:13:17 GMT 

Content-Type : application/auth-policy+xml 

Content-Length: (...) 

<?xml version="l . 0" encoding^ "UTF- 8 " ? > 

< rule set xmlns= "urn : ietf : params : xml : ns : common-policy" 
xmlns : sc= "urn : ietf : params : xml : ns : pidf : caps " 
xmlns :pr= "urn : ietf : params : xml : ns : pre s- rule s " 

xmlns : xsi= "http : //www. w3 . org/2 001/XMLSchema- instance" 
xsi : schemaLocation= "urn : ietf :params :xml :ns :pres-rules"> 
<rule id="dsafa43232"> 
<conditions> 
<identity> 

<id entity^ "user2_publicl@home2 .net " /> 
</identity> 
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</conditions> 
<actions> 

<pr : sub-handling>allow</pr : sub-handling> 

</actions> 

< trans format ions > 

<pr :provide-services> 

<pr : all- services /> 
</pr : provide- services > 

<pr : provide -persons xpr : al 1 -persons / >< /pr : provide -persons > 

<pr : provide -unknown-attribute name= "sc : servcaps " >true</pr : provide -unknown- 
attribute> 
</transf ormations> 

</rule> 
</ruleset> 



2. XCAP 201 (Created) response (XCAP server to XCAP client) - see example in table A.8.3-2 

After the XCAP server has performed the necessary authorization checks on the originator to ensure the 
XCAP chent is allowed to create a file, the XCAP server sends an XCAP 201 (Created) response to the 
XCAP client. 

Table A.8.3-2: XCAP 201 (Created) response (XCAP server to XCAP client) 



HTTP/1.1 201 Created 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Etag: "bbb" 

Date: Thu, 08 Jan 2004 10:50:35 GMT 
Content-Length: 



3 . XCAP PUT request (XCAP client to XCAP server) - see example in table A,8,3-3 

The XC/yi* client adds a new rule to the previously created presence authorization policy by generating a new 
XCAP request. The new rule blocks the user named sip:user3_public l@home3.net to see presence 
information. 

Table A.8.3-3: XCAP PUT request (XCAP client to XCAP server) 



PUT http: //xcap.homel . net /services/pres- rules /users /user 1/ps .xml/ — /permission- 

statements/ruleset/rule%5b2%5d HTTP/1 . 1 
User-Agent : IMS subscriber 
Date: Thu, 08 Jan 2004 10:13:27 GMT 
Content-Type: application/xcap-el 
Content -Length: (...) 

<rule id="fdsjkf"> 
<conditions> 
<identity> 

<id entity= "user3_publicl@home2 .net"/> 
</identity> 
<conditions> 
<actions> 

<pr : sub-handling>block</pr : sub-handling> 
</actions> 



4. XCAP 200 (OK) response (XCAP server to XCAP client) - see example in table A.8.3-4 

After the XCAP server has performed the necessary authorization checks, XML document validations and 
XML schema compliancy checks the XCAP server sends an XCAP 200 (OK) response to the XCAP client. 



Table A.8.3-4: XCAP 200 (OK) response (XCAP server to XCAP client) 



HTTP/1.1 200 OK 




Server: Apache/1.3.22 (Unix) 


mod_j)erl/l .27 


Etag: "bbb2" 




Date: Thu, 08 Jan 2004 10:50 


45 GMT 


Content -Length: 
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5 . XCAP DELETE request (XCAP cUent to XCAP server) - see example in table A.8.3-5 

The XCAP client decides to delete the rule for sip:user2_publicl @home2.net from the authorization policy. 
The XCAP client generates an XCAP DELETE request. 

Table A.8.3-5: XCAP DELETE request (XCAP client to XCAP server) 



DELETE http : //xcap . homel . net/services/pres- 

rules/users/userl/ps .xml/~~/ruleset /rule/statement [®id= "dsaf a43232 " ] HTTP/1 . 1 
Host: oper . example . com : 9999 
User-Agent: IMS subscriber 
Date: Thu, 08 Jan 2004 10:14:17 GMT 



6. XCAP 200 (OK) response (XCAP server to XCAP client) - see example in table A.8.3-6 

After the XCAP server has performed the necessary authorization checks on the originator to ensure the 
XCAP cUent is allowed to delete an entry from the resource list, the XCAP server sends an XCAP 200 (OK) 
response. 

Table A.8.3-6: XCAP 200 (OK) response (XCAP server to XCAP client) 



HTTP/1.1 200 OK 

Server: Apache/1.3.22 (Unix) modj>erl/l . 27 
Date: Thu, 08 Jan 2004 11:00:47 GMT 
Content -Length: 



7. XCAP GET request (XCAP client to XCAP server) - see example in table A.8.3-7 

The XCAP client wishes to check the result of the previous transaction by generating an XCAP GET request. 
Table A.8.3-7: XCAP GET request (XCAP client to XCAP server) 



GET http : //xcap . homel . net/services/pres-rules/users/userl/ps .xml HTTP/1 . 1 

User-Agent : IMS subscriber 

Date: Thu, 08 Jan 2004 11:13:17 GMT 

Content -Length: 



8. XCAP 200 (OK) response (XCAP server to XCAP client) - see example in table A.8.3-8 

After the XCAP server has performed the necessary authorization checks on the originator to ensure the 
XC/U^ cUent is allowed to fetch the resource Ust, the XC/^ server sends an XC/^ 200 (OK) response to the 
XCAP client including the authorization rules in the body of the response. 

Table A.8.3-8: XCAP 200 (OK) response (XCAP server to XCAP client) 



HTTP/1.1 200 OK 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Etag: "eiuuekksks" 

Date: Thu, 08 Jan 2004 11:50:35 GMT 
Content -Type :application/auth-policy+xml 
Content -Length: (...) 

<?xml version="l . 0" encoding="UTF-8"?> 

<ruleset xmlns= "urn: ietf :params :xml : ns : common-policy" 
xmlns : sc= "urn : ietf :params :xml : ns :pidf : caps " 
xmlns :pr="urn: ietf :params :xml :ns :pres-rules" 
xmlns :xsi= "http : / /www. w3 . org/2 001/XMLSchema- instance" 

xsi : schemaLocation= "urn : ietf :params :xml :ns :pres- rules " > 
<rule id="fdsjkf"> 
<conditions> 
<identity> 

<id entity= "user3_publicl@home2 .net"/> 
</ identity> 
<conditions> 
<actions> 

<pr : sub-handling>block</pr : sub-handling> 
< /act ions > 
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</ruleset> 



A.8.4 Storing external content (successful operation) 



UE (XCAP 
client) 



AS (XCAP 
server) 



HTTP server 



1 . HTTP PUT 


► 


^ 2. HTTP 201 (Creat€ 


)d) 


: 

3. XCAP PUT 


► 


► 

^ 4. XCAP 201 (Created) 


'■ 

5. HTTP GET 


6 HTTP 200 (OK) 




■ 

7. HTTP PUT 




^ 8. HTTP 200 (OK) 


► 


9. XCAP PUT 


'- ► 


► 

^ 10. XCAP 200 (OK) 


1 1 . HTTP DELETE 


^ 12. HTTP 200 (OK 


) 







Figure A.8.4.-1: XCAP ciient manipuiating liard-state presence document on XCAP server 
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Figure A. 8.4-1 shows a XCAP client manipulating hard-state presence document on a XCAP server when the presence 
document has an aggregated storing MIME object with the "application/pidf+xml" content type and any of its 
extensions. The details of the signalling flows are as follows: 

1 . HTTP PUT request (XCAP client to XCAP server) - see example in table A.8.2-1 

In order to store the content, the XCAP client generates an HTTP PUT request containing the MIME object 
in the body of the request. The request-URI points to the directory where the content is stored and shows the 
name of the file to be created. 

Table A.8.4-1 : HTTP PUT request (XCAP client to XCAP server) 



PUT http : //operator . example . com/services/users /bill/pictureX HTTP/1 . 1 

User-Agent : IMS subscriber 

Date: Thu, 08 Jan 2004 10:13:17 GMT 

Content-Type: image/jpeg 

Content -Length: (...) 

{pictureX.jpg} 



2. HTTP 201 (Created) response (XCAP server to XCAP client) - see example in table A.8.4-2 

After the XC/VP server has performed the necessary authorization checks on the originator to ensure the 
XCAP client is allowed to create a file the HTTP server sends an HTTP 201 (Created) response to the cUent. 

Table A.8.4-2: HTTP 201 (Created) response (XCAP server to XCAP client) 



HTTP/1.1 201 Created 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27Content-Type : text/html 
Date: Thu, 08 Jan 2004 10:50:35 GMT 
Content-Length: 



3. XCAP PUT request (XCAP client to XCAP server) - see example in table A.8.2-3 

The XCAP chent generates an XCAP PUT request in order to store XML encoded presence document which 
includes a URI reference to the MIME object stored on the XCAP server. The AUID part of the request URI 
is 'pidf-manipulation' as defined in RFC 4827 [34]. 

Table A.8.4-3: XCAP PUT request (XCAP client to XCAP server) 



PUT http : //xcap . example . com/ services/pidf -manipulation/users /bill/pidf .xml HTTP/1 . 1 

User-Agent : IMS subscriber 

Date: Thu, 08 Jan 2004 10:13:27 GMT 

Content-Type : application/pidf+xml 

Content -Length: (...) 

<?xml version="l . 0" encoding="UTF-8"?> 

<presence xmlns="urn: ietf :params :xml :ns :pidf " 

xmlns : rp= "urn: ietf :params :xml :ns :pidf : rpid" 

xmlns :ext="urn: ietf :params :xml :ns :ext-cont " 

xmlns :p="urn: ietf .params :xml :ns :pidf :data-model" 

xmlns :xsi="http: / /www.w3 .org/2001/XMLSchema-instance" 

xsi : schemaLocation= "urn : ietf : params :xml :ns : resource -lists " 

entity= "sip :bill@example . com" > 

<tuple id="123sd"> 
<status> 

<bas i c>open< /bas i c> 
</status> 

< contact >s ip :bill@example . com< /contact > 

</tuple> 

<p :person> 

<rp : activities xrp: vacation/ ></rp: activities > 
<ext : photo 

http : //operator .example . com/ services/users /bill/pictureX. jpg 
</ext :photo> 
</p :person> 
</presence> 
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4. XCAP 201 (Created) response (XCAP server to XCAP client) - see example in table A.8.4-4 

After the XCAP server has performed the necessary authorization checks, XML document validations and 
XML schema compliancy checks the XCAP server sends an XCAP 201 (Created) response to the XCAP 
client. 

Table A.8.4-4: XCAP 201 (Created) response (XCAP server to XCAP client) 



HTTP/ 1.1 2 01 Created 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Etag: "cccl" 

Date: Thu, 08 Jan 2004 10:50:45 GMT 
Content -Length: 



5 . HTTP GET request (XCAP cUent to XCAP server) - see example in table A.8.4-5 

The XCAP client wishes to fetch the MIME object from the XCAP server. The client generates an HTTP 
GET request. The request URl points to the directory where the object is stored and indicates the name of the 
file to be fetched. 

Table A.8.4-5: HTTP GET request (XCAP client to XCAP server) 



GET http : //operator . example . com/services/users/bill/pictureX HTTP/1 . 1 

Host: oper . example . com : 9999 

User-Agent : IMS subscriber 

Date: Thu, 08 Jan 2004 10:43:17 GMT 

Accept: image/jpeg 

Content -Length: 



6. HTTP 200 (OK) response (XCAP server to XCAP client) - see example in table A.8.4-6 

After the XCAP server has performed the necessary authorization checks on the originator to ensure the 
XCAP cUent is allowed to fetch the file the XCAP server sends an HTTP 200 (OK) response having the 
object in the body to the XCAP client. 

Table A.8.4-6: HTTP 200 (OK) response (XCAP server to XCAP client) 



HTTP/1.1 200 OK 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Date: Thu, 08 Jan 2004 11:00:47 GMT 
Content -Type : image/jpeg 
Content -Length: (...) 

{pictureX} 



7. HTTP PUT request (XCAP client to XCAP server) - see example in table A.8.4-7 

The XCAP client wishes to modify the earlier stored MIME object by replacing the picture X with a new 
picture X with new content. To modify the object the XCAP client generates an HTTP PUT request using the 
same request URI as has been used for the modified (old) object. The new object is conveyed in the body of 
the request. 

Table A.8.4-7: HTTP PUT request (XCAP client to XCAP server) 



PUT http : //operator . example . com/services/users /bill/pictureX HTTP/1 . 1 

User-Agent : IMS subscriber 

Date: Thu, 08 Jan 2004 11:13:17 GMT 

Content-Type: image/jpeg 

Content -Length: (...) 

{pictureX.jpg} 
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8. HTTP 200 (OK) response (XCAP server to XCAP cUent) - see example in table A.8.4-8 

After the XCAP server has performed the necessary authorization checks on the originator to ensure the 
XCAP client is allowed to replace the existing MIME object with the new one the XCAP server sends an 
HTTP 200 (OK) response to the XCAP client. 

Table A.8.4-8: HTTP 200 (OK) response (XCAP server to XCAP client) 

HTTP/1.1 200 OK 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Date: Thu, 08 Jan 2004 11:50:35 GMT 
Content -Length: 



9. XCAP PUT request (XCAP client to XCAP server) - see example in table A.8.4-9 

The XCAP client wishes to remove the MIME object from his presence information. The XCAP client 

generates an XCAP PUT request to modify the XML encoded presence document to remove the reference to 
the MIME object from the presence document. The request URI contains a node selector to the requested 
tuple according to RFC 4825 [33]. 

Table A.8.4-9: XCAP PUT request (XCAP client to XCAP server) 

PUT http : //xcap . example . com/services/pidf -manipulation/users/bill/pidf . xml/~~/presence/person 
HTTP/1 . 1 

Date: Thu, 08 Jan 2004 11:13:37 GMT 
If-Match: "cccl" 

Content-Type: application/xcap-el 
Content -Length: (...) 

<p:person> 

<rp:activities><rp:vacation/></rp:activities> 
</ p:person> 



10. XCAP 200 (OK) response (XCAP server to XCAP cUent) - see example in table A.8.4-10 

After the XCAP server has performed the necessary authorization checks, XML document validations and 
XML Schema compliancy checks the XCAP server sends an XCAP 200 (OK) response to the XCAP cUent. 



Table A.8.4-10: XCAP 200 (OK) response (XCAP server to XCAP client) 



HTTP/ 1.1 200 OK 




Server: Apache/1.3.22 (Unix) 


mod perl/1.27 


Etag: "ccc2" 




Date: Thu, 08 Jan 2004 11:50 


59 GMT 


Content -Length: 





1 1 . HTTP DELETE request (XCAP client to XCAP server) - see example in table A.8.4-11 

The XCAP client removes the MIME object from the XCAP server by generating an HTTP DELETE 
request. 

Table A.8.4-11 : HTTP DELETE request (XCAP client to XCAP server) 



DELETE http : / / operator . example . com/ services/users /bill/pictureX HTTP/1 . 1 

Host: oper. example . com: 9999 

User-Agent : IMS subscriber 

Date: Thu, 08 Jan 2004 11:52:00 GMT 
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12. HTTP 200 (OK) response (XCAP server to XCAP cUent) - see example in table A.8.4-12 

After the XCAP server has performed the necessary authorization checks on the originator to ensure that the 
XCAP cUent is allowed to delete the object, the XCAP server sends an HTTP 200 (OK) response to the 
XCAP client. 

Table A.8.4-12: HTTP 200 (OK) response (XCAP server to XCAP client) 



HTTP/1.1 200 OK 

Server: Apache/1.3.22 (Unix) mod_j)erl/l . 27 
Date: Thu, 08 Jan 2004 11:52:35 GMT 
Content -Length: 
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